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ABSTRACT 


This  document  presents  the  specifications  of 
the  WWMCCS  host  to  front  end  protocols.  A 
brief  overview  of  the  WWMCCS  network  front 
end  protocol  architecture  is  presented.  The 
link  protocol  is  functionally  specified.  The 
^'channel'^  protocol  is  completely  specified. 
The  complete  channel  protocol  specification 
includes  a  narrative  overview  of  the  channel 
protocol  mechanisms,  a  detailed  treatment  of 
each  channel  protocol  message  and  event  type, 
and  a  complete  state  table.  A  meta¬ 
specification  for  the  service  access  proto¬ 
cols  is  presented. 
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NETWORK  FRONT  END  PROTOCOL  ARCHITECTURE  . 

< 

Netwo fk  Front  End 

A  network  front  end  (NFE)-  i‘s  a  computer  system  that  interfaces 
a  host  computer  and  terminals  to  a  network.  A  host  connected 
directly  to  a  network  must  support  the  often  large  and  complex 
protocol  interpreters  for  the  network  services.  An  NFE 
implements  these  protocol  interpreters  for  the  host.  An  NFE 
thus  relieves  the  host  of  a  considerable  burden  of  protocol 
processing.  A  front  ended  host  need  support  only  the 
relatively  simple  interpreters  for  the  host  to  front  end 
protocols.  This  frees  host  resources  for  applications  use. 
An  NFE  also  provides  terminal  access  to  the  network.  This 
further  frees  host  resources  and  also  provides  for  continued 
access  to  the  network  in  the  event  of  host  failure. 


NFE  Protocol  Architecture 

An  NFE  implements  two  different  sets  of  protocols  (see  Figure 

1)  : 

1.  the  protocols  for  the  network  communication  services, 
and 

2.  the  host  to  front  end  protocols. 

The  protocols  for  the  network  services  include: 

1.  a  link  protocol  for  communication  between  the  front 
end  and  the  local  packet  switch, 

2.  a  transport  protocol  for  reliable  data  transfer 
between  local  and  remote  subscriber  processes,  and 


NEE  Protocol  Architecture 


3.  one  or  more  higher  order  service  protocols  for:,  e.g., 
a  network  virtual  terminal  or  a  file  transfer 

service. 

The  host,  to  front  end  protocols  include: 

1.  a  link  protocol  for  communication  between  the  host 
and  the  front  end, 

2.  a  "channel"  protocol  for  reliable  data  transfer 
between  host  and  front  end  processes,  and 

3.  for  each  network  (or  other)  service  supported  by  the 
front  end,  a  "service  access"  protocol  which  provides 
for.  mutual  access  between  host  applications  and  the 
service. 


The  interpreters  for  these  protocols  have  their  apposites*  in 
the  host. 


As  Figure  1  indicates,  both  the  network  services  and  the  host  to 
front  end  protocols  are  layered.  The  network  layers  are,  from 
bottom  to  top:  the  link  layer,  the  transport  layer,  and  the 
higher  order  service(s)  layer(s).  The  host  to  front  end  layers 
are,  from  bottom  to  top:  the  link  layer,  the  channel  layer,  and 
the  service  access  layer. 


4  "Apposite":  Having  the  same  syntactic  relation.  E.g.,  in 
Figure  1,  the  channel  protocol  interpreter  in  the  host  and  the 
channel  protocol  interpreter  in  the  front  end  are  each  other's 
apposites. 


Ndte  oh  the-  Specifications 
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NOTE  ON  THE  SPECIFICATIONS 


Specifying  the  Link  Protocol 

The  link  protocol  definition  depends  on  the  link  hardware. 
Thus,  the  link  protocol  cannot  be  specified  without  reference 
to  a  particular  installation.  However,  the  properties  of  the 
virtual  communications  medium  that  the  link  protocol 
•implementation  must  provide  have  been  functionally  specified 
in  the  present  document.  When  a  link  protocol  satisfying  this 
functional  specification  has  been  accepted  for  a  given 
installation,  the  complete  link  protocol  specification  should 
be  appended  to  the  present  document. 


Specifying  the  Channel  Protocol 

The  channel  protocol  definition  is  implementation  independent. 
Thus,  the  channel  protocol  has  been  completely  specified  in 
the  present  document.  Included  in  this  specification  is  a 
descriptive  model  of  the  interface  between  a  channel  protocol 
interpreter  (CPI)  and  any  service  access  protocol  interpreters 
(SAPIs)  or  other  processes  that  communicate  directly  with  a 
CPI.  The  interface  between  a  CPI  and  the  link  protocol 
interpreter  is  to  be  defined  by  the  link  protocol.  Therefore, 
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the  CPI-1  ink  interface  has  hot  be.en  specified  in  the  present 
document . 


Specifying  the  Servi ce  Access  Protocols 

The  service  access  protocol  definitions  depend  on  the  services 
to  which  they  provide  access.  Thus,  the  service  access 
protocols  cannot  be  specified  without  reference  to  the 
particular  services.  For  the  same  reason,  they  cannot  be 
functionally  specified.  However,  to  ensure  uniform 
documentation,  a  meta-specification  of  the  service  access 
protocols  is  presented  in  the  present  document.  Whenever  a 
service  access  protocol  satisfying  this  meta-speci f ication  has 
been  designed,  the  complete  service  access  protocol 
specification  should  be  appended  to  the  present  document. 


Note:  every  SAPI  communicates  directly  with  its  CPI.  This 
direct  communication  is  defined  by  the  channel  protocol  (see 
Channel  Interface).  In  some  cases,  processes  other  than  SAPIs 
may  communicate  with  one  another  using  the  channel  protocol 
implementation  as  their  communications  medium,,  Such  processes 
also  communicate  directly  with  their  CPIs.  Whenever  such  a 
process  is  to  be  implemented,  the  complete  specification  of 
its  use  of  the  channel  interface  and,  if  appropriate,  its  use 
of  service  access  protocol  messages  (see  Specifying  Service 
Access  Protocols)  should  be  appended  to  the  present  document. 


Link  Protocol'  Specification 


LINK  PROTOCOL 
Specification 


The  hardware  link  between  the  host  and  the  front  end  may  differ 
from  site  to  site.  Thus,  the  link  protocol  cannot  be  defined 
without  reference  to  a  given  installation.  For  each 
installation,  a  link  protocol  must  be  implemented  which  provides 
efficient  bi-directional  communication,  i.e.,  which  efficiently 
uses  the  available  host  and  front  end  resources  as  well  as  the 
communications  hardware.  In  addition  to  efficiency,  the  link 
protocol  implementation  must  provide  the  channel  protocol 
interpreters  (CPIs)  with  a  virtual  communications  medium  having 
the  following  properties: 

1.  the  appearance  of  full  duplex  communication, 

independently  of  whether  the  link  itself  is  full  or  half 
duplex , 

2.  delivery  of  data  in-order  and  without  duplication  or 
loss, 

3.  flow  control, 

4.  bit  stream  transparency, 


5. 

fault  no 

tification,  and 

6. 

quality 

of  service  defined  as 

a) 

an  undetected  bit  error  rate  less 

than 

lfl**-l 2 

b) 

undetected  data  loss  rate  less 
and 

than 

10**-15 

c) 

undetected  misdelivery  rate  less 

than 

10**-15 . 

If  the  link  protocol  does  not  provide  the  CPIs  with  a  virtual 


Link  Protocol  Specification 


•communications  medium  satisfying  these  criteria  without 
exception,  their  correct  operation  cannot  be  guaranteed. 


When  a  link  .protocol  satisfying  these  criteria  has 
the  complete  link  protocol  specification  should 
the  present  document.  Either  an  existing  or  a  new 
may  be  used.  If  an  existing  link  protocol 
specification  should  already  include  the  following 


been  accepted, 
be  appended  to 
link  protocol 
is  used,  its 
information : 


1)  a  reference  to  the  document  describing  the  link 
protocol  used, 

2)  the  version  of  the  protocol, 

3)  the  options  implemented, 

4)  the  parameter  values  used,  such  as  time-out  values, 
etc . 

5)  a  detailed  description  of  any  local  conventions  or 
modifications  to  the  protocol. 


If  any  of  this  information  is  missing,  the  specification  should 
be  augmented  to  include  it. 

If  the  link  protocol  accepted  has  been  especially  designed  for  a 
particular  host-front  end  configuration,  then  a  link  protocol 
specification  must  be  written.  This  specification  should  follow 
as  closely  as  possible  the  method  of  specification  used  in  the 
present  document. 
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SAPI 


to  Link  level  from  Link  level 


Figure  2:  CHANNEL  PROTOCOL  INTERPRETER  FUNCTIONS 


CHANNEL  PROTOCOL 


Specification 


Overview 


The  host  to  front  end  channel  protocol  defines  the  virtual 
communications  medium  for  the  service  access  protocol 
interpreters  (SAPIs)  (see  Figure  1).  This  communications  medium 
appears  to  the  SAPIs  as  a  set  of  host  to  front  end  "virtual 
channels",  each  of  which  will  support  a  single  service  access 
connection.  The  channel  protocol  provides  for  establishing  and 
terminating  these  channels  and,  together  with  the  link  protocol, 
provides  for  duplicate  free,  loss  free,  and  error  free  data 
exchange,  which  may  he  either  ordered  with  flow  control  or 
unordered  without  flow  control. 


The  units  of  communication  between  channel  protocol  interpreters 
(CPIs)  are  called  "channel  protocol  messages".  The  units  of 
communication  at  the  interface  between  a  CPI  and  an  SAPI  are 
called  "channel  interface  events".  The  channel  protocol  defines: 

1)  the  channel  messages  and  channel  interface  events, 

2)  their  use  in  establishing  and  terminating  channels  and  in 

effecting  the  flow  of  data  over  them,  and 

3)  the  states  of  each  end  of  a  channel  together  with  the 

state  transition  rules. 

Each  CPI  consists  functionally  of  a  channel  interface,  channel 
machines,  and  a  multiplexor/demultiplexor  (see  Figure  2).  The 
channel  interface  provides  access  to  the  channels  for  the  SAPIs. 


9 


CHANNEL  PROTOCOL 
Overview 

Each  channel  machine  maintains  the  state  of  one  end  of  a  channel. 
The  multiplexor/demultiplexor  multiplexes  messages  coming  from 
the  channel  machines  and  formats  them  for  transmission  via  the 
link  level.  It  filters  messages  coming  from  the  link  level  and 
demultiplexes  them  to  their  respective  channel  machines. 

cjosely  allied  with  each  CPI  is  an  HFP  Maintenance  Service 
process  that  participates  in  initializing  host-front  end 
communication,  records  errors  reported  by  the  CPI.('S),  and 
communicates  these  error  reports  between  apposite  CPIs. 

Channel  Protocol  Messages 

There  are  five  types  of  channel  protocol  messages:  Begin, 
Transmit,  Execute,  End,  and  Nop.  A  message  of  a  given  type 
may  be  either  a  Command  or  a  Response. 

Begin_Commands  and  Begin_Responses  are  used  by  CPIs  to 
establish  channels  between  them. 

Transmi t_Commands  and  Transmi t_Responses  are  used  by  CPIs  to 
effect  data  exchange  over  the  channels.  The  use  of 
Transmi t_Commands  and  Transmi t_Responses  provides  for 
maintaining  order  and  flow  control. 

Execute_Commands  and  Execute_Responses  are  also  used  by  CPIs 
to  effect  data  exchange  over  the  channels,  but  the  use  of 
Execute_Commands  and  Execute_Responses  does  not  provide  for 
maintaining  order  or  flow  control. 
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CHANNEL  PROTOCOL 
Overview 

End_Commands  and  End_Respcnses  are  used  by  CPIs  to  terminate 
one  dr  more  of  the  channels  between  them. 

Nops  are  used  by*  CPIs  as  filler  when  channel  protocol  messages 
do  not  completely  fill  link  protocol  frames. 

Channel  Machines 

A  channel  machine  consists  functionally  of  a  state  machine,  a 
transmission  controller,  and  a  channel  interface  (see  Figure 
2)  . 

The  state  machine  maintains  the  state  of  its  end  of  the 
channel.  The  state  machine  changes  state  in  response  to  the 
messages  and  interface  events  received  by  the  channel  machine. 

The  transmission  controller  provides  message  flow  control, 
duplicate  message  detection,  and  out  of  order  message 
detection  (see  Transmission  Control)  . 

The  channel  interface  receives  channel  interface  events  from 
the  SAPI  and  the  state  machine,  performs  consistency  checks  on 
them,  and  passes  them  on  to  the  state  machine  or  the  SAPI, 
respectively. 


CHANNEL  PROTOCOL 

Overview 

Channel.  Mul t.i pi exor/Demulti plexor  > 

The  channel  multiplexor/demultiplexor  performs  multiplexing, 
demultiplexing,  formatting,  and  filtering  functions  for  the 
CPI.  Messages  generated  by  the  CPI  are  formatted  according  to 
the  channel  protocol  message  formats.  Messages  from  the 
channel  machines,  the  filter,  and  the  demultiplexor  are 
multiplexed  into  a  single  stream  and  passed  to  the  link  level. 
The  multiplexor  ensures  that  each  channel  receives  its  share 
of  the  link  level  bandwidth. 

Messages  received  from  the  link  level  are  checked  for 
correctness  and  consistency.  Messages  failing  these  checks 
are  filtered  out  of  the  data  stream.  The  appropriate  Response 
(if  any)  is  formulated  and  passed  to  the  multiplexor  for 
transmission  to  the  apposite  CPI.  The  HFP  Maintenance  Service 
is  notified  of  the  error.  Messages  passing  these  checks  are 
sent  to  the  demultiplexor. 

The  demultiplexor  passes  each  message  to  the  appropriate 
channel  machine,  if  possible.  If  there  is  no  channel  machine 
to  which  to  pass  the  message,  the  demultiplexor  formulates  the 
appropriate  Response  (if  any),  passes  the  Response  to  the 
multiplexor  for  transmission  to  the  apposite  CPI,  and  notifies 
the  HFP  Maintenance  Service  of  the  error. 


Message  Formatting  and  Filtering 


Message  Formatting  and  Filtering 


This  section  specifies  the  format  of  channel  protocol  messages 
and  the  consistency  checks  to  be  performed  on  each  message  before 
accepting  it. 


Channel  Protocol  Message  Formatting 


In  order  to  simplify  decoding  and  buffer  management,  all 
channel  protocol  messages  have  the-  same  basic  format.  This 
format  is  shown  in  Figure  3  (see  p.  14). 


Parts  of  Messages 


Each  message  has  three  parts. 


Pcirt  Function 

HEADER  comprises  the  fields  containing  the 

information  for  executing  the  channel 
protocol  for  this  message  (see  below) . 

PAD  is  zero  or  more  bits  long  (an 

installation  parameter)  and  serves 
only  to  place  TEXT  on  a  boundary 
convenient  for  both  parties  to  the 
protocol . 

TEXT  contains  a  service  access  or  other 

higher  level  protocol  message.  Since 
the  Size  field  (defined  below) 
contains  the  number  of  bits  in  the 
entire  message,  and  since  the  HEADER 
is  7  2  bits  long,  the  size  of  TEXT  is: 

(Size)  -  (size  of  PAD)  -  72. 
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Message  -Formatting  and  -Filtering 


Field 

Name 

Field 

Size 

(bits) 

HEADER' 

/ - 

| 

-\ 

I 

Size 

I  16 

1 

1 

1 

i 

Type 

1 

I  3 

1 

1 

C/R 

i  i 

1 

Credit 

I  4 

! 

Seq 

i  — 

1  4 

1 

Ack 

i  4 

I 

1 

(not  used) 

j  - - 

1  4 

1 

Group 

i 

1  12 

1 

1 

I 

1 

Member 

1 

I  1.6 

1 

1 

1 

1 

1 

1 

Control 

1 

1  8 

1 

1 

(Commands) 

1 

1 

PAD 

iNote  A 

| 

1 

1 

TEXT 

1 

I 

INote  B 

1 

\ - 

1 

1 

1 

1 

-/ 

Alternate 

Field  Alternate 

Size  Field 

(bits)  Name 


Service 

(BEGIN  Command) 


I  8  |  Status 

I  I  (Responses) 


Note  A:  The  size  of  PAD  is  an  installation  parameter. 
Note  B:  The  size  of  TEXT  is  computed  by: 

(Size)  -  (size  of  PAD)  -  72. 


Figure  3:  CHANNEL  PROTOCOL  MESSAGE  FORMAT 


Message  Formatting  and  Filtering 


HEADER  Fields 

The  functions  of  the  HEADER  fields  are  defined  below. 


Field 

Size 


Type 


C/R 


Credit 


Seq 


Ack 


Function 

specifies  the  number  of  bits  in  the 
entire  message.  This  field  is  IS  bits 
long*  It  allows  the  representation  of 
message  sizes  of  up  to  65,535  bits. 
Actual  maximum  message  size  is  an 
installation  parameter  which  may  be 
less  than  this. 

specifies  the  message  type: 


Begin  0 
Transmit  1 
Execute  3 
End  4 
Nop  5 


specifies  whether  the  message  is  a 
Command  (C/R  =0)  or  a  Response  (C/R  = 
1)  . 

specifies  the  number  of 
Transmit_Commands  beyond  the  number 
specified  by  the  Ack  field  (see 
below) ,  which  the  sender  of  this 
message  is  prepared  to  receive. 

specifies,  in  a  Transmit_Command ,  its 
sequence  number.  Specifies,  in  all 
other  messages  (except 
Begin_Commands) ,  the  sequence  number 
of  the  last  Transmi t_Command  sent  by 
the  sender  of  this  message.  In 
Begin_Commands,  both  the  Seq  and  Ack 
fields  are  replaced  by  the  Service 
field. 

specifies  the  sequence  number  of  the 
last  in-sequence  Transmi t_Command 
correctly  received  by  the  sender  of 
this  message  (except  in 
Begin_Commands) .  In  Begin_Commands, 
both  the  Seq  and  Ack  fields  are 
replaced  by  the  Service  field. 


Service 


specifies,  in  Begin_Commands,  the  SAPI 


Message  Formatting 


and  Filtering 


G/roup 


Member 


Control 


Status 


to  which  the  channel  is  to  be 
established.  The  Service  field 
occupies  the  same  space  as  the  Seq  and 
Ack  fields  in  all  other  types  of 
messages . 

specifies  the  channel  group  whicn  the 
message  references  (see  Addressing 
Conventions) . 

specifies  the  channel  which  the 
message  references  within  the  channel 
group  (see  Addressing  Conventions)  . 

specifies  control  information  for 
Execute_Commands  and  End_Command's. 
Its  use  in  other  Commands  is  currently 
undefined.  The  Control  field  in 
Commands  occupies  the  same  space  as 
the  Status  field  in  Responses. 

specifies  status  information  in 
Responses.  The  Status.  field  in 
Responses  occupies  the  same  space  as 
the  Control  field  in  Commands. 


Channel  Protocol  Message  Filtering 

When  a  channel  protocol  message  is  received  by  a  CPI,  it  must 
be  checked  for  validity.  Before  the  message  is  demultiplexed, 
the  filter  function  of  the  CPI  performs  validity  checks  on  it 
(see  Figure  2).  These  validity  checks  are  for: 


Message  Size: 
the  contents 
length,  of  a 
either  from 


Compare  message  length  for  agreement  with 
of  the  Size  field.  It  is  assumed  that  the 
message  can  be  determined  independently 
the  hardware  o.r  from  the  link  protocol 


interpreter 


Message  Formatting-  and  Filtering: 


Note:  The  hardware  determined  length  may  be  greater  than 
the'  contents  of  the  Size  field.  (In  some  cases.,  the 
hardware  will  pad  the  message  out  to  a  word  boundary  on 
the  receiving  system.)  In  such  a  case,,  the  validity1 
check  can  only  be  for  the  hardware,  determined  length 
being  less  than  the  contents  of  the  Size  field:. 


Message  Type:  check  the  contents  of  the  Type  field  to 
determine  whether  or  not  the  value  represents  a  valid 
Type. 

Message  too  la rge:  check  the  Size  of  the  message  to 
determine  whether  or  not  it  exceeds  the  maximum  allowed 
at  this  site. 


Group  and  Member  fields;  check  the  Group  and  Member 
fields  to  determine  whether  or  not  the  message  references 
a  valid  Group  and  Member. 

Note:  Since  this  check  is  tantamount  to  demultiplexing  a 
message,  it  may  be  performed  as  part  of  that  function. 

Service:  if  the  message  is  a  Begin_Command ,  then  check  to 
determine  whether  or  not  a  valid  SAPI  is  being  requested. 

Control  field:  check  the  Control  field  (if  defined)  of 
each  Command  to  determine  whether  or  not  the  value  is 
valid  for  this  Command  type. 

Status  field:  check  the  Status  field  of  each  Response  to 
determine  whether  or  not  the  value  is  valid  for  this 
Response  type. 

If  an  error  is  detected  in  a  message,  the  normal  procedure  is 
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to  log  the  error  in  an  error  log,  send'  a  Response  (if  any) 
notifying  the  apposite  CPI,  and  discard  the  message.  There 
are  two  exceptions.  First)  if  a  message  fails  either  the  Size 
or  Type  field  checks,  the  CPI  cannot  trust  any  of  the 
information  in  the  HEADER  to  be  correct.  Therefore,  the  CPI 
cannot  determine  what  kind  of  Response  to  respond  with. 
Second,  if  the  CPI  detects  an  error  in  a  Response,  it  cannot 
send  a  Response  to  a  Response.  In  either  case,  the  CPI  uses 
the  HFP  Maintenance  Service  to  notify  the  apposite  CPI  of  the 
error. 

Note:  since  a  CPI  only  communicates  with  only  one  other  CPI 
(and  not  with  many) ,  it  is  not  necessary  that  all  of  the  above 
checks  be  made  at  all  times.  The  checks  for  valid  Service, 
Control,  and  Status  may  be  made  during  a  testing  phase  of 
operation  and  omitted  during  normal  operation. 


Message  Formatting  and-  Filtering 


Status  Codes 


Every  Response  contains  a  Status  field  whose 
the  success  of  or  the  reason  for  failure 
which  it  is  a  Response.  The  Status  field 
are: 


value  indicates 
of  the  Command  to 
value  conventions 


a.  zero  indicates  that  the  action  initiated  by  the 
Command  was  successful; 

b.  1  to  31  indicate  errors  applicable  to  all  Commands  at 
the  channel  protocol  level; 

c.  32  to  63  indicate  errors  specific  to  individual 
Command  types  at  the  Channel  Protocol  level; 

d.  64  to  255  are  reserved  for  internal  use  within  the 
host  and  front  end. 


The  codes  common  to  all  Responses  are  summarized  below. 


Status  Meaning 


0 

1 


2 


3 


5 


6 


Command  was 


successful . 


Channel  non-ex 
fields  of 
Begin_Command) 
unknown  to  the 


istent:  the 
a  Command 
referenced  a 
receiving  CPI 


Group  and 
(other 
channel 


Member 
than  a 
machine 


Illegal 

machine 

Command 


state:  a  Command  referenced  a  channel 
which  was  in  a  state  for  which  the 
is  an  illegal  input. 


Command  not  implemented:  a  Command  was 
received  whose  Type  is  legal  but  not 
implemented.  Currently  this  can  only  be  a 
Begin_Command  or  an  Execute  Command. 


Message  too  long:  the  number  of  bits  in  the 
Command  exceeded  the  maximum  permitted  by  the 
receiving  CPI. 

Service  access  protocol  message  error:  an 
error  in  the  service  access  protocol  message 


Message  Formatting  and  Filtering 


contained  in  the  TEXT  field  of  the  Command  was 
detected  by  the  SAPI. 

7  Illegal  Control  field  value:  the  Control  field 

of  the  Command  contained  an  undefined  value. 


The  Status  codes  specific  to  each  Response  are  given  under  its 
specification  (see  Commands  and  Responses).. 


Message  Multiplexing  and  Demultiplexing 

Message  Multiplexing  and  Demultiplexing 

Addressing  Conventions 

Each  bi-directional  service  access  connection  is  supported  by 
a  single  host  to  front  end  channel.  Usually,  many  such 
channels  must  be  maintained  over  a  single  physical  connection. 
A  number  is  therefore  assigned  to  each  channel  to  identify 
it.  It  may  be  desirc^ble  to  group  channels  (e.g.,  according  to 
service)  and  manipulate  the  group  as  a  whole.  For  this 
reason,  the  channel  identifier  is  divided  into  two  fields 
called  Group  and  Member.  A  channel  number  whose  Member  field 
has  the  value  zero  refers  to  all  channels  of  the  group.  The 
channel  protocol  defines  the  following  conventions  for  these 
fields: 

1)  An  End_Command  with  Group  not  equal  to  zero  and 
Member  equal  to  zero  terminates  all  channels  in  the 
specified  group. 

2)  An  End_Command  with  Group  equal  to  zero  and  Member 
equal  to  zero  terminates  all  channels  between  the 
two  apposite  CPIs. 

The  Group  and  Member  fields  in  a  message  HEADER  are  specified 
to  be  large  enough  (12  and  1G  bits,  respectively)  to  allow  an 
installation  to  place  all  channels  in  a  single  group,  to  place 
each  channel  in  its  own  group,  or  to  use  the  full  power  of  the 
two-dimensional  channel  address  structure.  A  channel  is 
assigned  its  number  by  the  CPI  which  initiates  its 
establishment.  Since  apposite  CPIs  refer  to  a  particular 
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channel  by  the  same  channel  number,  and  because  either  CPI  may 
initiate  channel  establishment,  name  space  conflicts  must  bp 
avoided.  This  is  accomplished  by  pre-assigning  half  the  name 
space  to  each  end.  The  high  order  bit  of  the  Group  field  is 
used  to  distinguish  the  two  ends.  The  host  owns  the  half  of 
the  name  space  with  the  high  order  bit  of  the  Group  field 
equal  to  zero.  The  front  end  owns  the  half  of  the  name  space 
with  the  high  order  bit  of  the  Group  field  equal  to  one. 


Multiplexing 

The  unit  of  multiplexing  is  the  channel  protocol  message.  All 
messages  from  the  channel  machines  and  any  that  may  be 
generated  by  the  filtering  and  demultiplexing  functions  are 
passed  to  the  multiplexor  for  multiplexing  into  the  link 
level's  single  data  stream. 


Demuli 


Messages  received  via  the  link  level  from  the  apposite  CPI  are 
passed  to  the  demultiplexor  in  accord  with  the  state  of  flow 
control  at  the  link  level  interface.  The  messages  are  then 
checked  for  correctness  and  consistency  (see  Message 
Formatting  and  Filtering) .  If  a  message  passes  these  checks, 
the  demultiplexor  uses  the  Group  and  Member  fields  of  the 
message  HEADER  to  determine  which  channel  machine (s)  the 
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message  addresses*.  The  message  is  then  passed  to  the 
indicated  „  channel  machines (s) .  Xf  the  message  is  a 
Begin^Command ,  a  new  channel  machine  will  be  created  to 
process  this  request  for  a  connection. 
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HOST  FRONT  END 


Host  to  Front  End  Protocols 


Figure  4:  CHANNEL  PROTOCOL  FLOW  CONTROL  POINTS 
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Transmission  Control 

Together,  the  channel  and  link  protocols  provide  for  duplicate- 
free,  loss-free,  and  error-free  data  exchange.  The  exchange  of 
data  between  apposite  CPIs  may  be  .  either  ordered  with  flow 
control  ("controlled  transmission"),  or  unordered  without  flow 
control  ("uncontrolled  transmission").  The  link  protocol 
provides  for  error  detection,  and  lost  and  duplicate  message 
detection.  However,  duplicate  messages  may  be  re-introduced  by 
retransmissions  at  the  channel  level.  Duplicates  thus  introduced 
are  detected  by  the  CPI  and  removed. 

In  addition  to  defining  these  functions  for  ensuring  the 
integrity  of  the  data  stream,  the  channel  protocol  also  defines 
the  interaction  between  controlled  and  uncontrolled  transmission, 
and  the  flow  control  mechanisms  for  the  individual  channels. 

Controlled  Transmission  Mechanisms 

The  channel  protocol  implementation  provides  a  controlled  data 
stream  to  apposite  SAPIs.  The  controlled  data  stream 
preserves  order  (i.e.,  data  is  delivered  to  the  receiving  SAPI 
in  the  same  order  in  which  it  was  presented  by  the  sending 
SAPI)  and  is  flow  controlled.  Flow  control  mechanisms  are 
employed  at  three  different  points  in  the  controlled  data 
stream  between  apposite  SAPIs  (see  Figure  4).  This  threefold 
flow  control  prevents  a  slow  receiving  SAPI  from  being  overrun 
by  a  faster  sending  SAPI.  The  channel  level  flow  control  also 
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helps  to  ensure  fair  use  of  the  link  level  by  preventing  any 
single  channel  machine  from  flooding  the  multiplexor  with 
messages.  The  controlled  transmission  data  stream  is  provided 
via  the  Transmi t_Command  and  the  Credit,  Seq,  and  Ack  fields 
of  other  Commands  and  Responses  and  via  the  s_ready  and 
ci__ready  channel  interface  events. 

Credit:  flow  control  between  apposite  channel  machines  is 
provided  by  the  receiver  of  Transmit__Commands  granting  Credit 
to  the  sender.  Credit  can  be  sent  in  any  channel  protocol 
message  (except  Ehd_Commands  and  End_Responses) .  The  Credit 
field  of  a  message  contains  the  number  of  Transmit_Commands 
the  sender  may  send  beyond  the  last  message  acknowledged.  In 
other  words,  the  value  of  the  Ack  field  added  modulo  16  to  the 
value  of  the  Credit  field  is  the  largest  sequence  number  the 
receiving  channel  machine  is  currently  willing  to  accept.  The 
flow  control  mechanisms  are  described  in  greater  detail  in  the 
section  on  Flow  Control  below. 

Sequence  Numbers:  order  is  preserved  by  assigning  a  unique 
sequence  number  to  each  Transmit_Command .  Sequence  numbers 
are  assigned  in  ascending  order  modulo  16.  The  sequence 
numbers  are  the  basis  for  ordering,  duplicate  detection, 
acknowledgement,  and  flow  control.  Each  message  type  (except 
Begin_Commands)  contains  a  Seq  field.  In  messages  other  than 
Transmi t_Commands ,  Seq  specifies  the  sequence  number  of  the 
last  Transmi  t__Command  sent  by  the  sender  of  the  message.  In 
8egin_Commands  the  value  of  Seq  must  be  zero. 
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Acks:  delivery  confirmation  of  T  r  a  n  sm  f t^Ccmma  nd  s  is 
accomplished  via  acknowledgements.  Each  message  type  (except 
Begin_Commands):  contains  an  Ack  field.  An  Ack  is  the  sequence 
number  of  the  last  Transmit_Command  correctly  received  by  the 
receiving  channel  machine.  The  Ack  confirms  the  delivery  of 
all  messages  with  'Sequence  numbers  less  than  or  equal  to  the 
sequence  number  in  the  Ack  field.  In  Begin_Commands,.  the 
value  of  Ack  must  be  zero.  Arithmetic  and  comparisons  on  Acks 
is  done  modulo  16,  and,  in  order  to  avoid  ambiguous 
interpretation  of  sequence  numbers,  a  channel  machine  cannot 
have  more  than  eight  unacknowledged  messages  outstanding. 

Sending  Queue:  since  the  sending  channel  machine  may  send  data 
to  its  apposite  faster  than  it  can  be  accepted,  flow  control 
is  used  to  prevent  the  sender  from  flooding  the  receiver. 
Therefore  the  sending  channel  machine  has  a  queue  for  messages 
waiting  until  flow  control  .allows  them  to  be  sent.  Messages 
from  the  controlled  data  stream  are  entered  into  this  queue 
first  in  first  out  (FIFO).  Messages  from  the  uncontrolled 
data  stream  may  or  may  not  not  be  entered  into  this  queue 
according  to  a  FIFO  discipline  (see  Uncontrolled 
Transmission) . 
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Channel  Interface  Flow  Control :  a  channel  machine  and  an  SAPI 
communicate  via  the  channel  interface.  Flow  control  must  be 
provided  across  this  interface  to  prevent  the  SAPI  from 
flooding  the  channel  machine  and  vice-versa.  In  the  model  of 
the  interface  described  in  this  specification,  the  s_ready  and 
ci_ready  events  provide  flow  control  across  the  channel 
interface.  The  s_ready  event  indicates  to  the  channel  machine 
the  number  of  ci_transmit_c  events  the  SAPI  is  able  to  accept. 
Similarly,  the  ci_ready  event  indicates  to  the  SAPI  the  number 
of  s_transmit_c  events  the  channel  machine  is  able  to  accept. 

Receiving  Queue:  since  the  channel  machine  may  send  data  to 
the  SAPI  faster  than  the  SAPI  can  accept  it,  flow  control  is 
required  across  the  channel  interface.  Therefore,  the  channel 
machine  has  a  queue  for  events  waiting  until  the  channel 
interface  flow  control  allows  them  to  be  sent  to  the  SAPI. 
Events  from  the  controlled  data  stream  are  entered  into  the 
queue  first  in  first  out  (FIFO).  Events  from  the  uncontrolled 
data  stream  may  or  may  not  be  entered  into  this  queue 
according  to  a  FIFO  discipline.  (See  Uncontrolled 


Transmission) 
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Figure  5a:  THE  MOVING  WINDOW  MODEL 
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Controlled  Transmission  Procedures 

The  Moving  Window  Model ;  the  mechanisms  used  in  the  Channel 
Protocol  for  preserving  message  order,  detecting  duplicates, 
and  controlling  data  flow  are  based  on  the  moving  window 
model.  In  this  model,  a  window  is  seen  to  be  sliding  along 
the  sequence  number  line  (see  Figure  5a) .  Only  messages  whose 
sequence  numbers  are  within  the  window  are  acceptable. 
Sequence  numbers  less  than  the  left  edge  of  the  window  denote 
messages  that  have  already  been  acknowledged.  The  left  edge 
itself  denotes  the  sequence  number  of  the  last  in-order 
message  received.  The  width  of  the  window  denotes  the  amount 
of  Credit  currently  extended  to  the  sender,  i.e.,  the  number 
of  messages  which  the  receiver  is  currently  willing  to  accept. 
Sequence  numbers  greater  than  or  equal  to  the  right  edge  of 
the  window  denote  messages  that  are  not  yet  acceptable  because 
they  are  beyond  the  receiver's  current  ability  to  accept  them. 

For  each  direction  of  data  flow,  there  are  two  windows  (see 
Figures  5b  and  5c),  one  maintained  by  the  sender  (the 
"s_window")  arid  one  maintained  by  the  receiver  (the 
"r_window").  Data  flow  is  controlled  by  the  receiver.  The 
receiver's  r_window  represents  the  receiver's  image  of  the 
state  of  the  data  flow:  the  last  message  acknowledged  by  the 
receiver  and  the  amount  of  Credit  extended  to  the  sender.  The 
sender's  s_window  represents  the  sender's  image  of  the 
receiver's  r_window:  the  last  acknowledged  message  and  the 
amount  of  Credit  the  sender  has  been  notified  of.  Because  of 


31 


Figure  6:  CHANNEL  MACHINES  WITH  s  and  r  windows 
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messages  in  transit  or  messages  los't,  the  sender's  s_window 
may  not  agree  with  the  receiver's  r_window. 

Since  data  can  flow  in  both  directions,  each  channel  machine 
maintains  both  an  r_window  and  an  s_window  (see  Figure  6) . 
For  a  receiving  channel  machine's  r_window  ("an  R_CM's 
r_window") ,  the  left  edge  represents  the  sequence  number  of 
the  last  acknowledgement  sent  to  the  sending  channel  machine 
("the  S_C M " ) .  The  right  edge  of  the  R_CM's  r_window  is 
computed  by  adding  together  modulo  16  the  last  amount  of 
credit  extended  to  the  S_CM  and  the  value  of  the  left  edge. 
This  gives  the  largest  sequence  number  that  the  R_CM  is 
currently  able  to  accept.  Since  the  R_CM  may  receive  several 
messages  before  it  can  acknowledge  the  first,  the  R_CM  must 
keep  track  of  the  sequence  number  of  the  last  message  it  has 
received.  For  an  S_CM's  s_window,  the  left  edge  represents 
the  sequence  number  of  the  1ast  acknowledgement  received  from 
the  R_CM.  The  right  edge  is  computed  by  adding  together 
modulo  16  the  Credit  and  Ack  field  of  the  last  message 
received  from  the  R_CM.  This  is  the  largest  sequence  number 
that  the  S_CM  should  send.  Since  the  S_CM  may  send  messages 
in  advance  of  those  that  are  acknowledged,  the  S_CM  must  keep 
track  of  the  sequence  number  of  the  next  message  to  be  sent. 

Dupl icate  Detection;  duplicate  Transmit_Commands  may  be 
introduced  into  the  controlled  data  stream  by  retransmissions. 
If  a  Transmi t_Command  arrives  at  the  R_CM  with  a  sequence 
number  less  than  the  value  of  the  left  edge  of  its  r  window, 
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the  Transmi t_Command  is  a  duplicate.  The  -duplicate  is 
discarded  and  the  S_CM  is  no.t  notified. 

Ordering:  Transmic_Commands  may  arrive  out-of-order  due  to 
events  at  the  link  level  or  due  to  retransmissions.  If  a 
Transmi-t_Command  arrives  with  a  sequence  number  more  than  one 
greater  than  the  left  edge  of  the  R_CM's  r__window,  the 
Transmi t_Command  is  out  of  order.  The  R_CM  may  keep  the 
message  if  it  has  sufficient  buffer  space  or  it  may  discard 
it.  In  either  case,  the  R_CM  should  send  a  Transmit_Response 
to  the  S_CM  indicating  that  an  out-of-order  message  was 
received  (Status  =  35)  and  with  the  Ack  field  set  to  the  value 
of  left  edge  of  the  R_CM's  r_window.  This  will  cause  the  S_CM 
to  retransmit  all  Transmi t_Commands  from  the  sequence  number 
of  the  Ack  field  in  the  Transmit_Response  to  the  sequence 
number  of  the  last  message  sent  by  the  S_CM. 


Flow  Control :  flow  control  must  be  provided  both  at  the 
channel  interface  and  between  apposite  channel  machines.  The 
channel  interface  events  s_ready  and  ci_ready  are  used  to 
control  flow  across  the  channel  interface  for  a  particular 
channel.  The  s_ready  event  indicates  to  the  channel  machine 
the  number  of  ci_transmi t_c  events  the  SAPI  is  able  to  accept. 
The  ci_ready  event  indicates  to  the  SAPI  the  number  of 
s__transmi t_c  events  the  channel  machine  is  able  to  accept.  It 
is  assumed  that  events  are  not  lost  between  the  SAPI  and  the 
channel  interface.  The  number  of  ci_transmit_c  or 
s_transmit_c  events  allocated  by  each  additional  s_ready  or 
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ci_ready  event  replaces  the  previous  allocation. 

Note:  this  particular  channel  interface  model  should  not  be 
viewed  as  an  implementation  specification.  The  channel 
interface  model  only  specifies  the  properties  that  a  channel 
interface  must  have.  Many  mechanisms  may  satisfy  these 
properties. 

When  a  channel  machine  receives  a  message  from  its  apposite, 
it  uses  the  Ack  and  Credit  fields  to  update  its  s_window.  The 
left  edge  of  the  s_window  is  set  equal  to  the  Ack  field.  The 
right  edge  is  set  equal  to  the  sum  modulo  16  of  the  Ack  field 
plus  the  Credit  field.  The  channel  machine  can  now  send 
messages  to  its  apposite  as  long  as  the  sequence  numbers 
assigned  are  less  than  the  value  of  the  right  edge  of  its 
s_window. 

When  a  channel  machine  receives  a  Transmit_Command  that  is  in 
order  and  not  a  duplicate,  it  advances  the  left  edge  of  the 
r_window  by  one  (modulo  16).  It  acknowledges  this  message 
(thereby  acknowledging  any  others  that  have  not  been 
acknowledged  as  well) .  No  more  than  8  unacknowledged  messages 
can  be  left  outstanding.  If  the  width  of  the  r_window  is  near 
zero  and  the  channel  machine  has  sufficient  allocation  to  pass 
data  on  to  its  SAPI,  additional  Credit  should  be  extended  to 
the  sending  channel  machine. 

Communicating  Flow  Control  Information:  although  the 
controlled  data  stream  consists  solely  of  Transmit_Cbmmar.ds, 
other  channel  protocol  messages  carry  flow  control 
information.  This  section  provides  a  table  of  the  values  of 
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the  Seq,  Ack,  and  Credit  fields  in  these  messages. 


Begin_Command  Seq: 

Ack*: 

Credit: 

Begin_Response:  Seq: 

Ack: 

Credit: 

Execute_Command :  Seq: 

Ack : 

Credit: 

Execute_Response:  Seq: 

Ack: 

Credit: 

Transmi t_Command :  Seq: 

Ack : 

Credit: 

Transmi t_Response :  Seq: 

Ack : 

Credit: 

End  Command:  Seq: 


field'  used  for  Service  Code 
field  used  for  Service  Code 
specifies  the  initial  credit 
to  the  receiver 

zero 

zero 

specifies  the  initial  credit 
to  the  receiver 

specifies  the  sequence  number 
of  the  last  Transmit_Command 
s  en  t 

specifies  the  sequence  number 
of  the  last  in  order 
Transmit_Command  correctly 
received 

specifies  the  new  credit 
value 

specifies  the  sequence  number 
of  the  last  Transmit_Command 
sent 

specifies  the  sequence  number 
of  the  last  in  order 

Transmit_Command  correctly 
received 

specifies  the  new  Credit 
value 

specifies  the  sequence  number 
of  this  Transmi t_Command 
specifies  the  sequence  number 
of  the  last  in  order 

Transmit_Command  received 

correctly 

specifies  the  new  credit 
value 

specifies  the  sequence  number 
of  the  last  Transmi t_Command 
sent 

specifies  the  sequence  number 
of  the  last  in  order 
Transmi t_Command  received 

correctly 

specifies  the  new  Credit 
value 

specifies  the  sequence  number 
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of  the  last  Transmi t_Command 
sent 


Ack : 

specifies  the  sequence  number 
of  the  last  Transmi t_Command 

' 

correctly  received  before  the 
channel  was  terminated 

Credit: 

irrelevant 

EncMResponse: 

Seq: 

specifies  the  sequence  number 
of  the  last  Transmi t_Command 
sent 

Ack: 

specifies  the  sequence  number 
of  the  last  Transmit_Command 
correctly  received  before  the 
channel  was  terminated 

Credit: 

irrelevant 
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Figure  7:  INTERACTION  OF  CONTROLLED  AND  UNCONTROLLED  TRANSMISSION 


Transmission  Control 


Uncontrolled  Transmission 

The  channel  protocol  implementation  provides  an 
uncontrolled  data  stream  to  apposite  SAPIs.  The 
uncontrolled  data  stream  does  not  guarantee  that  order  will 
be  preserved,  nor  does  it  provide  flow  control.  The 
uncontrolled  data  stream  provides  a  means  to  expedite  data 
transfer  with  respect  to  the  controlled  data  stream.  In 
addition,  an  "attention"  to  interrupt  the  SAPI  can  be 
associated  with  the  expedited  message.  The  uncontrolled 
data  stream  also  provides  a  means  to  synchronize  delivery 
of  data  in  the  uncontrolled  data  stream  with  the  controlled 
data  stream.  Similarly,  an  attention  to  interrupt  the  SAP! 
can  be  associated  with  the  synchronized  message.  The 
uncontrolled  data  stream  is  provided  in  the  channel 
protocol  by  the  Execute _Command  and  the  ExecuteJResponse . 
Figure  7  shows  the  interaction  between  controlled  and 
uncontrolled  transmission. 

Expedited  Da ta  Flow:  an  Execute_Command  may  be  sent  with 
the  Synchronize  bit  of  the  Control  field  set  to  zero.  In 
this  case,  delivery  of  the  Execute_Command  is  expedited. 
This  means  that  the  Execute_Command  is  placed  at  the  head 
of  the  Sending  Queue  for  delivery  to  the  link  level.  when 
the  Execute_Command  arrives  at  the  receiving  channel 
machine  its  TEXT  is  placed  at  the  head  of  the  Receiving 
Queue  for  delivery  to  the  SAPI. 

Note:  Whether  or  not  Execute_Commands  are  expedited  by  the 
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link  protocol  implementation  depends  on  the  facilities 
provided  by  the  link  protocol..  The  channel  protocol  does 
not  require  that  the  link  level  provide  this  facility; 
however,  it  would  be  useful  if  available. 

The  Attention  bit  of  the  Control  field  of  an  expedited 
Execute_Command  may  be  set  to  one.  If  the  Attention  bit  is 


set,  the 

receiving 

channel  notifies 

the 

SAPI 

via 

attention 

or  an 

interrupt  when 

the 

TEXT 

of 

Execute_Command  is  placed  at  the  head  of  its  the  Receiving 
Queue.  The  attention  or  interrupt  is  a  special  signal  t,o 
the  SAPI  notifying  it  of  important  data  waiting  to  be 
processed.  If  the  Attention  bit  is  set  to  zero,  the 
channel  machine  places  the  TEXT  of  the  Execute_Command  at 
the  end  of  its  Receiving  Queue  and  sends  no  attention  to 
the  SAPI.  In  this  case  the  Execute_Command  is  synchronized 
( see  below) . 

Synchronized  Data  Flow:  an  Execute_Command  may  be  sent  with 
the  Synchronize  bit  of  the  Control  field  set  to  one.  In 
this  case,  the  sending  channel  machine  places  the 
Execute_Command  at  the  end  of  its  Sending  Queue  for 
delivery  to  the  link  level.  The  Execute_Command  is  sent  to 
the  apposite  channel  machine  in  the  normal  course  of  events 
and  is  not  expedited.  When  the  apposite  channel  machine 
receives  the  Execute_Command ,  it  places  the  TEXT  at  the  end 
of  its  Receiving  Queue.  If  the  Attention  bit  is  set  to 
one,  it  immediately  notifies  the  SAPI  by  an  interrupt  or  an 
attention  that  important  data  is  waiting  to  be  read.  The 
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SAPI  should  process  the  queued  data  as  quickly  as  possible 
in  order  to  receive  the  TEXT  of  the  Execute_Command  and  act 
■on  it. 

Note:  The  effect  of  the  Attention  bit  is  not  propagated 
ahead  of  a  synchronized  Execute_Command  until  it  reaches 
the  Receiving  Queue.  If  such  an  effect  is  to  be  achieved, 
the  sending  SAPI  should  cause  its  channel,  machine  to  first 
send  a  synchronized  Execute_Command  with  the  Attention  bit 
set,  and  then  to  send  an  expedited  Execute_Command  with  the 
Attention  bit  set.  This  will  cause  an  attention  to  be 
propagated  ahead  of  the  synchronized  Execute_Command » 

Termination 

Channels  may  be  terminated  in  two  ways:  flushing  and  non¬ 
flushing.  A  flushing  termination  causes  all  queued  data  to 
be  discarded  and  causes  the  channel  machine  to  enter  a 
terminating  state.  A  non-flushing  termination  allows  all 
queued  data  to  be  sent  before  causing  the  channel  machine 
to  enter  a  terminating  state. 

Flushing  Termination:  when  a  channel  machine  is  requested 
to  perform  a  flushing  termination,  it  discards  all  queued 
data  in  both  the  Receiving  and  Sending  Queues  and  sends  an 
End_Command.  Any  data  tht  arrives  after  the  End_Command  is 
sent  is  discarded.  When  the  End_Command  arrives  at  the 
apposite  channel  machine,  all  data  in  its  Receiving  Queue 
is  discarded  and  the  SAPI  is  notified  by  a  channel 
interface  event. 


41 


Transmission  Control 


Non- flushing  Termination: 

when  a  channel 

machine 

is 

requested  to 

perform  a 

non- flushing  te 

rmination. 

the 

chanri.ei  machine 

discards  all 

data  that  was 

queued  in 

its 

Receiving  Queue  for  the  SAPI,  and  enters  an  End_Command  at 
the  end'  of  its  Sending  Queue.  Any  data*  that  arrives  after 
the  End_Command  has  been  entered  in  the  Sending  Queue  is 
discarded.  When  the  last  Transmit_Command  is  sent,  the 
channel  machine  then  sends  the  End_Command  and  enters  a 
terminating  state.  When  the  End_Command  arrives  at  the 
apposite  channel  machine,  it  is  placed  at  the  end  of  the 
Receiving  Queue,  The  End_Command  is  not  acted  upon  until 
the  last  data  has  been  delivered  to  the  SAPI. 

Non-Flushing  End  Deadlock  Avoidance 

Both  of  the  apposite  SAPIs  using  a  virtual  channel  can 
simultaneously  request  non-flushing  termination  of  the 
channel.  Each  channel  machine  must  withhold  sending  the 
End_Command  until  the  data  which  it  has  queued  for  sending 
to  the  other  drains  out.  A  deadlock  will  occur  if  neither 
channel  machine  can  drain  its  Sending  Queue  of  data  for  the 
other.  This  deadlock  can  be  avoided  by  the  following 
procedure. 

If  a  channel  machine  is  requested  to  perform  a  non-flushing 


termination, 


it  shall 
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1)  discard  all  data  queued  in  its  Receiving  Queue  for 
the  SAPI  that  requested  the  non-flushing 
termination. 

2)  continue  to  extend  Credit  to  its  apposite  CPI 
(this  allows  its  apposite  to  drain  its  Sending 
Queue  of  data  toward  it);  and 

3)  if  the  channel  machine  does  receive 

Transmit_Commands  from  its  apposite,  it  shall 
acknowledge  and  discard  them  (since  the  SAPI  has 
requested  termination,  the  data  need  not  he  passed 
to  it) . 

If  the  above  procedure  is  followed,  both  of  the  apposite 
SAPIs  may  request  non-flushing  termination  without  a 
deadlock  occurring. 
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Notation  arid  Nomenclature  Conventions 
for  the 

Channel  Protocol 


Notation 


States:  all  states  names  are  printed  with  all  capital  letters.  If 
the  state  name  consists  of  two  or  more  words,  the  words  are 
separated  by  an  t  d.r.^core  (_) .  Examples:  NULL,  SENDER_PENDIMG. 


Commands:  all  Command  names  are  of  the  form: 

<command  name>_Command 

where  <command  name>  is  one  of  the  following: 

Begin 

End 

Execute 

Transmit 


The  first  letter  of  each  word  is  capitalized. 
Examples:  Begin_Command ,  End_Command . 


Responses:  all  Response  names  are  of  the  form: 

<response  name>_Response 

where  <response  name>  has  the  same  range  as  Ccommand  name>.  The 
first  letter  of  each  word  is  capitalized. 

Examples:  Begin_Response ,  End_Response . 


Events:  all  names  of  events  caused  by  the  SAPI  are  either  of  the 
form: 


s_<interface  event  name>_<event  suffix> 

where  <interface  event  name>  is  one  of  the  following: 

begin 

end 

execute 
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and  Cevent  suffix>  is  either 

c  indicating  a  Command 

or  r  indicating  a  Response 

or  of  the  form: 

s_< interface  event  name> 

where  <interface  event  name>  is  one  of  the  followinq: 

identify 

ready 

status 

All  names  of  events  caused  by  a  channel  machine  are  either  of  the 
form: 

c_<interface  event  name>_<event  suffix> 

where  <interface  event  name>  is  one  of  the  following: 

begin 

end 

execute 
transmi t 

and  <event  suffix>  is  the  same  as  above 
or  of  the  form: 


c_<interface  event  name> 

where  <interface  event  name>  is  one  of  the  following: 

accept 

ready 

reject 

status 

Event  names  are  all  lower  case.  Examples:  s_begin_c,  c_begin_c/ 
s_ready,  c_status. 
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Valid/Invalid:  an  invalid  Command  or  Response  is  one  that  has 
failed  to  pass  one  or  more  consistency  checks  performed  by  the 
CPI.  Most  invalid  Commands  and  Responses  are  detected  by  the 
multiplexor/demultiplexor  and  are  handled  at  that  time., 
Transmit_Commands  may  arrive  out-of-order  or  may  be  outside  the 
flow  control  window.  These  are  also  handled  by  the  channel 
machine  and  are  described  in  the  state  table. 

Acceptable/Unacceptable;  the  channel  machine  checks  events  for 
consistency  and  accepts  or  rejects  them  via  the  c_accept  or 
c_reject  events. 

Status  f  £:  indicates  that  the  Command  corresponding  to  this 
Response  was  not  successful.  It  indicates  that  the  attempt  to 
establish  a  virtual  channel  has  failed. 

Status  =  2:  indicates  that  the  channel  machine  was  not  in  a  legal 
state  to  receive  the  Command  corresponding  to  this  Response. 

Status  =  3j9:  indicates  that  the  channel  machine  was  in  the 
SENDER_DRAINING  state  and  discarded  the  Command  corresponding  to 
this  Response. 

Flushing/Non-Flushing:  channels  may  be  terminated  in  two  ways: 

Flushing:  any  data  queued  for  transmission  is  discarded  at 
the  time  the  termination  is  requested. 

Non-Flushing:  the  termination  request  is  not  acted  on  until 
all  data  queued  for  transmission  has  been  sent  (see 
Termination) . 

Log  the  error:  if  the  channel  machine  detects  an  error,  the  error 
and  any  ocher  diagnostic  information  should  be  written  on  a 
permanent  file.  In  some  cases,  the  error  may  be  reported  to  the 
HFP  Maintenance  Service. 


Channel  Machine  States 


NULL:  a  channel  machine  in  this  state  does  not  have  an  active 
channel . 


SENDER  PENDING:  a  channel  machine  in  this  state  is  attempting  to 
establish  a  channel.  It  has  sent  a  Regin_Command  and  is  waiting 
for  a  Begin_Response. 
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RECEIVER  PENDING;  a  channel  machine  in  this  state  has  received  a 
Begir._Command  and  is  waiting*  for  the  s_ibegin_r  event  from  the  . 
SAPI. 

SENDER  TAKING  BACK:  a  channel'  machine  in  this  state  has  been 

requested  to  terminate  the  channel  while  it  was  in  the 
SENDER__PENDING  state  and  has  sent  an  End_Command  before  it  has 
received  the  Begin_Response . 

RECEIVER  TAKING  BACK:  a  channel  machine  in  this  state  has 
received  an  End_Command  while  it  was  in  the  REC El VER_P ENDING 
state  before  the  SAPI  has  responded  to  the  c_beg,in_c  event. 

ESTABLISHED:  a  channel  machine  in  this  state  has  established  a 
channel  with  its  apposite. 

SENDER  DRAINING:  a  channel  machine  in  this  state  has  been 

requested  to  terminate  the  channel  without  flushing  any  data. 
The  channel  machine  is  sending  all  queued  Transmi t__Commands 
before  sending  the  En<X_Response. 

RECEIVER  DRAINING:  a  channel  machine  in  this  state  has  received  a 
non-flushing  End__Command  and  is  waiting  until  the  SAPI  has  read 
all  of  the  data  queued  for  it  before  sending  the  End_Response . 

SENDER  TERMINATING:  a  channel  machine  in  this  state  either 

1)  has  been  requested  by  the  SAPI  to  terminate  the  channel 
and  flush  any  data  not  yet  sent,  or 

2)  has  been  in  the  SENDER__DRAINING  state,  has  sent  the  last 
Transmi t_Command ,  and  has  also  sent  the  End_Command. 

RECEIVER  TERMINATING:  a  channel  machine  in  this  state  either 

1)  has  received  a  flushing  End__Command  and  is  waiting  for 
an  s_end__r  event  from  the  SAPI,  or 

2)  has  been  in  the  RECEI VER_DRAINING  state,  has  passed  the 
last  c_transmit__c  event  and  the  c_end_c  event  to  the 
SAPI,  and  is  now  waiting  for  the  s_end_r  event. 
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COMMANDS  AND  RESPONSES 


Introduction 

The  following  section  defines  the  channel  protocol  commands  and 
Responses,  For  each  Command  and  each  Response,,  there  is  a 
presentation  of: 

1.  its  function, 

2.  when  it  is  sent, 

3.  the  sending  channel  machine's  state  table  for  it, 

4.  the  receiving  channel  machine's  action  upon  receiving  it 

a)  in  the  normal  case  and 

b)  in  case  of  error, 

5.  the  receiving  channel  machine's  state  table  for  it, 

6.  any  subsequent  action  by  the  receiver 

a)  in  the  normal  case  and 

b)  in  case  of  error, 

7.  any  subsequent  action  by  the  sender 

a)  in  the  normal  case  and 

b)  in  case  of  error, 

8.  the  semantics  of  the  fields  of  the  HEADER  for  this 
Command  or  Response,  and 

9.  the  semantics  of  TEXT  for  this  Command  or  Response. 

The  conventions  followed  in  the  state  tables  are  given  in  the 
section  entitled  "Notation  and  Nomenclature  Conventions  for  the 
Channel  Protocol." 
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Function 


A  Begin_Command  is  used  by  a  channel  machine  to  request 
apposite  to  join  it  in  establishing  a  host  to  front 
channel . 


i  ts 
end 


When  sent 

When  an  acceptable  s_begin__c  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  a  Begin  Command. 


Sending  States 


CURRENT  STATE 

1 

INPUT 

'"'I . 

1  NEXT  STATE 

1  OUTPUT 

. 1"  " 

1  COMMENT 

(SUB-STATE) 

1 

1 

1 

1 

. I _ 

NUU. 

1 

1 

acceptable 

1  SENDER 

I  c  accept 

1 

I  initial ize  channel 

1 

1 

s_beg 1 n_c 

1  PENDING 

! . 

|  Begin_Corc.nnnN 

1  machine 

I  _ 

Action  when  received 

In  the  normal  case :  a  channel  machine  receiving  a 
Begin_Command  is  in  the  NULL  state.  The  channel  machine  then 
causes  a  c_begin_c  event  in  order  to  notify  the  SAPI  specified 
by  the  Service  field  of  the  Begin_Command  that  a  channel  to  it 
has  been  requested  and  to  pass  to  it  the  TEXT  field  of  the 
Beg in_Command .  The  channel  machine  then  enters  the 
RECEIVERJPENDING  state. 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HE'P 
Maintenance  Service)  ,  discards  the  message,  and  sends  a 
Begin_Response  with  the  Status  code  proper  to  the  error  (see 
Status  codes  for  the  Beg in_Response ,  below). 
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Receiving  Spates 


CURRENT  STATE 

I  INPUT 

|  NEXT  STATE  . 

1  OUTPUT 

1  COMMENT 

(SUB-STATE) 

1 

1 

1 

1 

MU  IX 

1 

I  valid 

1  RECEIVER 

1 

1  c  heqin  c 

1 

1  initialize  channel 

1  Begin_Command 

1  PENDING 

1 . 

1  machine 

any  other 

1 

1  Begin  Command 

| - 

1 

1  log  the  error 

state 

1  (valid  or 

1 

i 

1 

|  invalid) 

1 

1 

1 

sequent  action  by  the  Receiver 

In  the  normal  case:  an  s_begin_r  event  with  Status  =  0  is 
caused  by  the  SAPI  in  response  to  the  c_begin_c.  The  channel 
machine  then  sends  a  Begin_Response  with  Status  =  0  and  enters 
the  ESTABLISHED  state. 

In  case  of  error:  an  s_begin_r  with  Status  i-  0  event  is  caused 
by  the  SAPI.  The  channel  machine  then  sends  a  Begin_Response 
with  Status  1  0  and  enters  the  NULL  state. 


Subsequent  action  by  the  Sender 

In  the  normal  case:  the  channel  machine,  having  sent  a 
Begin_Command ,  waits  for  a  Begin_Response.  If  the  channel 
machine  receives  a  Begin_Response  with  Status  =  0,  it  then 
notifies  the  SAPI  by  causing  a  c_begin_r  event  with  Status  =  0 
and  enters  the  ESTABLISHED  state. 

I n  case  of  error :  if  the  channel  machine  having  sent  a 
Be<j.in_  ^Command  receives  a  Begin_Response  with  Status  ^  0,  it 
notifies  the  SAPI  of  the  error  via  a  c_begin_r  event  with 
Status  ?  0  and  enters  the  NULL  state. 

Taking  back:  An  SAPI  having  requested  the  channel  machine  to 
establish  a  channel  may,  via  an  s_end_c  event,  request  the 
channel  machine  to  terminate  the  channel  before  it  receives 
the  expected  Begin_Response.  In  this  case,  the  channel 
machine  then  sends  an  End_Command  and  enters  the 
.SENDER  TAKING  BACK  state. 


Begin_Command 


Semantics  of  fields 

Type:  0  specifies  Begin. 

C/R:  0  specifies  Command. 

Credit:  specifies  the  number  of  Transmit_Commands  the  sending 
channel  machine  is  prepared  to  accept,  (see  Transmission 
Control) .  Its  value  may  be  zero. 

Service:  specifies  the  SAPI  to  which  the  channel  is  to  be 
established  (see  Message  Multiplexing  and  Demultiplexing) . 

Group  and  Member:  specifies  the  channel  that  is  to  be 
established . 

Control :  is  currently  undefined  for  the  Begin_Command . 


Semantics  of  TEXT 


TEXT  contains 


the  service  access 


protocol 


message. 
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Begin_Response 


Function 


A  Begin_Response  is  used  by  a  channel  machine  either  to 
indicate  the  successful  establishment  of  a  host  to  front  end 
channel  as  requested  by  its  apposite  or  to  indicate  the  reason 
for  failure. 


When  Sent 

When  an-  acceptable  s_begin_r  event  has  been  caused  by  an  SAPI, 
the  channel  machine  sends  a  Begin_Response. 


Sending  States 


CURRENT  STATE 
(SUB-STATE) 


RECEIVER 

PENDING 


RECEIVER 

PENDING 


RECEIVER_ 
TAKING  BACK 


INPUT 

1  NEXT  STATE 

1 

i  OUTPUT 

1 

|  COMMENT 

1 

acceptable 

s_begin_r 

(Status=0) 

1  ESTABLISHED 

1 

1 

I 

I  c_accept 

1  Begin_Response 

1  (Status=0) 

! 

1 

I 

1 

1 

acceptabl e 
s__begin  r 
(Status?!!) 

1  NULL 

I 

1 

I 

j  c_accept 

1  Begin_Response 

I  (Status?0) 

1 

1 

1 

1 

1 

1 

acceptable 
s  begin  r 
(Status?!)) 

1 

1  NULL 

1 

1 

I  c_accept 

1  Begin_Response 

1  (Status^!)) 

1 

1 

1 

1 

Action  When  Received 


In  the  normal  case :  a  channel  machine  receiving  a 
Begin_Response  with  Status  =  0  is  in  the  SENDER_P ENDING  state. 
The  channel  machine  then  causes  a  c_begin_r  event  with  Status 
=  0  in  order  to  notify  the  SAPI  that  the  channel  has  been 
established  and  to  pass  to  it  the  TEXT  field  of  the 
Begin_Response.  The  channel  machine  then  enters  the 
ESTABLISHED  state. 

In  case  of  error:  if  a  channel  machine  receiving  a 
Begin_Response  with  Status  /  0  is  in  either  the  SENDER_P ENDING 
state  or  the  SENDER_TAKING_BACK  state,  it  causes  a  c__begin_r 
event  with  Status  ^  0  in  order  to  pass  the  TEXT  field  of  the 
Begin_Response  to  the  SAPI  and  enters  the  NULL  state;  if  a 
channel  machine  receiving  a  Begin_Response  with  Status  =  0  is 


-  54  - 


Begin_Response 


in  the  SENDER_TAKING_BACK  state,  it  takes  no  action  and  does 
not  change  state;  if  a  channel  machine  receiving  a 
Begin_Response  is  in  neither  the  SENDER_PENDING  state  nor  the 
SENDER_TAKING_BACK  state,  it  logs  the  error  (see  HFP 
Maintenance  Service)  but  does  not  change  state;  if  an 
inconsistency  in'  the  Begin_Response  has  been  detected,  the 
filter  logs  the  error  (see  Message  Formatting  and  Filtering, 
HFP  Maintenance  Service). 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 
! 

OUTPUT 

I 

1  COMMENT 
! 

1 

SENDER 

valid 

1 

1  ESTABLISHED 

c  begin  r 

1 

1 

PENDING 

Begin  Response 

I 

(Status=0) 

1 

(Status=0) 

1 

1 

1 

SENDER 

val  id 

|  NULL 

c  beqin  r 

1  _ . 

PENDING 

Begin  Response 

1 

(Status)^) 

1 

(Status^O) 

1 

1 

1 

1 

SENDER 

invalid 

!  SENDER 

c  beqin  r 

1 

1  log  the  error 

PENDING 

Begin  Response 

1  TERMINATING 

(Status?0) 

1 

End  Command 

I 

1 

(flushing) 

1 

1 

SENDER 

val  id 

1 . 

1 

1 

TAKING  BACK 

Begin  Response 

1 

1 

(Status=0) 

1 

1 

1 

SENDER 

val  id 

1  NULL 

c  beqin  r 

1 

1 

TAKING  BACK 

Begin  Response 

1 

(Status70) 

1 

(Status/0) 

1 

•  _  _ .  __  _  _ 

1 

_ 1 . . 

any  other 
state 


Begin_Response 
(valid  or 
inval id) 


log  the  error 


Subsequent  Action  by  the  Receiver 

In  the  normal  case:  the  channel  machine  exchanges  data  with 
its  apposite. 

In  case  of  error:  none  if  the  channel  machine  had  been  in 
either  the  SENDER_PENDING  state  or  the  SENDER_TAKING_BACK 
state;  had  it  been  in  any  other  state,  it  logs  the  error  but 
does  change  state. 
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Subsequent  Action,  by 

the  Sender 

In  the  normal  case 
its  apposite. 

:  the  channel  machine 

exchanges 

data 

with 

In  case  of  error: 

The  chahnel  machine 

returns  , to 

the 

NULL 

state. 


Semantics  of  Fields 

Type:  0  specifies  Begin. 

C/R:  1.  specifies  Response. 

Credit:  specifies  the  number  of  Transmit_Commands  the  sender 
of  the  Begin_Response  is  prepared  to  accept  (see  Transmission 
Control).  If  there  was  an  error,  the  content  of  this  field  is 
i rrelevant. 

Seq:  is  zero.  If  there  was  an  error,  the  content  of  this 
field  is  irrelevant. 

Ack:  specifies  zero  as  the  sequence  number  of  the  last  message 
correctly  received.  If  there  was  an  error,  the  content  of 
this  field  is  irrelevant. 

Group  and  Member:  specifies  the  channel  which  the 

Begin__Command  requested  to  be  established. 

Status  indicates  the  success  or  failure  of  the  attempt  to 
establish  the  channel.  The  following  Status  codes  are 
applicable  to  the  Beg in_Response : 

Status  Meaning 

0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 
fields  of  the  Begin_Command  referenced  a 
channel  machine  unknown  to  the  receiving  CPI. 

2  Illegal  state:  the  Begin_Command  referenced  a 
channel  machine  which  was  in  a  state  for  which 
the  Begin_Command  is  an  illegal  input. 

3  Command  not  implemented:  the  Begin_Command  is 
not  .implemented  by  the  receiving  CPI. 

5  Message  too  long:  the  number  of  bits  in  the 

Beg in_Commana  exceeded  the  maximum  permitted 
by  the  receiving  CPI. 
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6  Service  access  protocol  message  error:  an 

error  in  the  service  access  protocol  message 
contained  in  the,  TEXT  field  of  the 
Begln_Command  was  detected  by  the  SAPI. 

32  Channel  in  use-:  the  channel  referenced  in  the 
Begin_Command  was  already  assigned  (i.e.,  not 
in  the  NULL  state) . 

33  Service  not  implemented:  the  Service  field  in 
the  Begin_Command  specified  an  SAPI  not 
implemented  at  the  receiving  site. 

34  Insufficient  resources:  the  receiver  of  the 
Begin_Command  did  not  have  sufficient 
resources  for  establishing  the  host  to  front 
end  channel. 

37  Bad  channel  polarity:  the  high-order  bit  of 
the  Group  field  in  the  Begin_Command  had  the 
wrong  value. 

38  Service  not  operational:  the  Service  field  in 
the  Begin__Command  specified  an  SAPI  which  is 
implemented  at  the  receiving  site  but  which  is 
temporarily  unavailable. 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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End  Command 


Function 

An  End_Command  is  used  by  a  CPI  to  request  its  apposite  CPI  to 
join  it  in  terminating  a  host  to  front  end  channel,  a  group  of 
channels,  or  all  channels. 

A  CPI  sending  an  End_Command  has  two  options: 

1.  it  may  request  that  the  channel (s)  be  terminated 

immediately  ("flushing  termination"); 

2.  it  may  request  that  the  channel (s)  be  terminated 

only  after  any  data  queued  by  its  apposite  CPI  has 
been  passed  on  to  the  apposite  CPI's  SAPI  (s)  ("non¬ 
flushing  termination"). 

(For  further  discussion  also  see  Termination.) 


When  Sent 

When  an  acceptable  s_end_c  event  has  been  caused  by  an  SAPI, 
its  CPI  sends  an  End  Command. 
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End  Command 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

NEXT  STATE 

OUTPUT 

1 

1 

COMMENT 

NULL 

acceptable 

c  accept 

1 

s  end  c 

End  Command 

1 

(flushing,  from 

(flushing) 

1 

HFP  Maintenance 

1 

Service) 

• 

1 

SENDER 

acceptable 

SENDER 

c  accept 

1 

PENDING 

s  end  c  (flushing 

TAKING  BACK 

End  Command 

1 

or  nori-f  lushing) 

(flushing) 

1 

SENDER 

invalid 

SENDER 

c  beqin  r 

1 

log  the  error 

PENDING 

Begin  Response 

TERMINATING 

(Statuses) 

1 

End  Command 

1 

(flushing) 

1 

1 

RECEIVER 

acceptable 

NULL 

c  accept 

1 

PENDING 

s  end  c  (flushing 

End  Command 

1 

or  r.on-f lushing) 

(flushing) 

1 

SENDER 

acceptable 

c  accept 

1 

TAKING  BACK 

s  end  c  (flushing 

End  Command 

1 

or  non-flushing) 

(flushing) 

1 

1 

RECEIVER 

acceptable 

NULL 

c  accept 

1 

TAKING  BACK 

s  end  c  (flushing 

End  Command 

1 

or  non-flushing) 

(flushing) 

1 

ESTABLISHED 

acceptable 

SENDER 

c  accept 

1 

discard  any  queued 

s  end  c 

TERMINATING 

End  Command 

1 

data 

t 

(flushing) 

(flushing) 

1 

ESTABLISHED 

acceptable 

SENDER 

c  accept 

1 

discard  any  data 

(with  data 

s  end  c  (non- 

DRAINING 

1 

queued  for  SAPI; 

queued  for 

flushing) 

1 

send  data  to 

apposite 

1 

apposite  CPI;  olaco 

CPI) 

1 

End  Command  (non- 

1 

flushing)  at  end  of 

1 

send  queue; 

1 

acknowledge  but 

1 

1 

1 

ESTABLISHED 

acceptable 

SENDER 

c  accept 

1 

1 

discard  any  data 

(with  no 

s  end  c  (non- 

TERMINATING 

End  Command 

(non- 

1 

queued  for  SAPI; 

data  queued 

flushing) 

flushing) 

1 

acknowledge  but 

for 

1 

discard  any  incoming 

opposite 

1 

messages 

CP  1 1 

1 

1 

SENDER 

acceptable 

SENDER 

c  accept 

1 

1 

discard  any  queued 

DRAINING 

s  end  c 

TERMINATING 

find  Command 

1 

data 

( flushing) 

(flushing) 

1 

SENDER 

(acknowledgement 

SENDER 

End  Command 

(non- 

1 

DRAINING 

of  last  Transmit 

TERMINATING 

flushing) 

1 

Command 

1 

1 

RECEIVER 

acceptable 

NULL 

c  accept 

1 

discard  any  queued 

DRAINING 

s  end  c  (flushing 

End  Command 

! 

data 

or  -ion-flushing) 

(flushing) 

1 

1 

SENDER 

acceptable 

c  accept 

1 

1 

TERMINATING 

s  end  c  (flushing 

End  Command 

1 

or  non-flushing) 

(flushing) 

1 

RECEIVER 

acceptable 

NULL 

caccept 

1 

1 

TERMINATING 

s  end  c  (flushing 

End  Command 

1 

or  non- flushing) 

1  . 

(flushing) 

1 

1 

i 
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End  Command 


Ac tion  When  Received 

In  the  normal  case:  a  channel  machine  receiving  an  End  Command 
Is  ~Tn  eTtlTer  the  SENDER_PENDING  state,  the  ESTABLISHED  state, 
the  SENDER_DRAINING  state,  or  the  SENDER_TERMINAT1MG  state. 
If  the  End_Command  specifies  a  non-flushing  termination,  the 
channel  machine  first  waits  until  any  data  queued  for  the  SAPI 
has  been  read  by  the  SAPI  (see  Won-Flushing  End  Deadlock 
Avoidance).  If  the  End_Command  specifies  a  flushing 
termination,  the  channel  machine  discards  any  data  queued  for 
the  SAPI.  The  channel  machine  then  causes  a  c__end_c  event  in 
order  to  pass  the  TEXT  field  of  the  End_Command  to  the  SAPI. 
The  channel  machine  then  enters  the  RECEIVER_TAKIWG_BACK  state 
if  it  had  been  in  the  RECEI VER_PENDING  state,  the 
RECEIVER_TERMINATING  state  if  it  had  been  in  the 
RECEI VER_DRA INI NG  state,  or  the  NULL  state  if  it  had  been  in 
the  SENDER_TERMINATING  state. 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  discards  the  message,  and  sends  an 
End_Response  with  the  Status  code  proper  to  the  error  (see 
Status  codes  for  End  Response,  below) . 
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End  Command 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 


NEXT  STATE 


COMMENT 


End_Command 
(valid  or 
invalid,  flushing 
or  non-flushing) 


End  Response 


discard  the  message 


SENDER 

PENDING 


End_Command 
(valid  or 
invalid,  flushing 
or  non-flushing) 


c_end_c 

End_Response 


RECEI V£R_ 
PENDING 


valid  End  Command 


RECEI V£R_ 
TAKING  BACK 


RECEIVER 

PENDING 


inval id 
End  Command 


c^end_c 

End_Response 


log  the  error 


SENDER 

TAKING  BACK 


valid  End  Command 


c_end_c 

Endjlesponse 


RECEIVER 
TAKING- BACK 


valid  End  Command 


c_end_c 
Bnd^  Response 


ESTABLISHED 


valid  EndjCommand 
(flushing! 


RECEIVER 

TERMINATING 


c  end  c 


discard  any  data 
queued  for  BAPI  and 
for  apposite  CPI 


ESTABLISHED 
(with  data 
queued  for 
SAPI) 


valid  End  Command 
(non-flushing) 


RECEIVER 

DRAINING 


discard  any  data 
queued  for  apposite 
CPI;  place  c  end  c 
at  end  of  receive 
queue;  acknowledge 
but  discard  any 
incoming  messages 


ESTABLISHED 
(with  no 
data  queued 


valid  End^Command 
(non-f lushing) 


RECEIVER 

TERMINATING 


c  end  c 


discard  any  data 
queued  for  apposite 
CPI;  acknowledge  but 


for  SAPI) 

1 

1 

1 

1 

discard 

any  incomim 

i 

1 

1 

1 

1 

1 

1 

messages 

ESTABLISHED 

1 

inval  id 

1 

NULL 

I  c  end  c 

1 

log  the 

error 

1 

End  Command 

1 

1  End  Response 

1 

1 

(flushing  or 

1 

I 

1 

non-flushing) 

1 

1 

1 

1. 

1 

1 

SENDER 

1 

valid  End  Command 

1 

NULL 

I  c  end  c 

1 

1 

discard 

any  data 

DRAINING 

1 

(flushing! 

1 

1  End  Response 

1  ~ . 

1 

queued 

RECEIVER 

1 

1 

valid  End  Command 

1 

1 

RECEIVER 

1 

1  c  end  c 

1 

1 

discard 

any  data 

DRAINING 

1 

1 

(flushing) 

1 

TERMINATING  I 

1  __  _ 

1 

I 

queued 

SENDER 

1 

valid  End  Command 

1 

1 

NULL 

1 

1  c  end  c 

i 

TERMINATING 

1 

(flushing  or 

1 

! 

1 

1 

non- flushing) 

1 

1 

1 

1 

1 

SENDER 

1 

1 

inval id 

1 

1 

NULL 

1 

1  c  end  c 

1 

log  the 

error 

TERMINATING 

1 

End_Command 

1 

1 

1  End  Response 

1 

1 

1 

RECEIVER 

1 

valid  End  Command 

1 

NULL 

1 

1  c  end  c 

1 

TERMINATING 

1 

(flushing  or 

1 

1  End  Response 

1 

1 

1 

non-flushing) 

1 

1 

1 

1 

1 
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End  Command 


Subsequent  Action  by  the  Receiver 

In  the  normal  case:  a  s_end_r  event  with  Status  =  0  is  caused 
by  the  SAPI  in  response  to  the  c_end_c  event.  The  channel 
machine  then  sends  an  End_Response  with-  Status  =  0  and  enters 
the  NULL  state. 

In  case  of  error :  a  s__end_r  event  with  Status  ^  0  is  caused  by 
the  SAPI.  The  channel  machine  then  sends  an  End  Response  with 
Status  i  0  and  enters  the  NULL  state. 


Subsequent  Action  by  the  Sender 

In  the  normal  case :  if  a  non-flushing  termination  v/as 
specified,  the  channel  machine  continues  to  acknowledge 
Transmi t_Commands ,  to  extend  flow-control  Credit,  to  act  upon 
any  flow-control  information  contained  in  in-coming  Commands 
or  Responses,  and  to  discard  any  incoming  Commands  or 
Responses  until  it  receives  an  End_Command  or  an  End_Response . 

In  case  of  error :  the  channel  machine  notifies  the  SAPI  of  the 
error  via  a  c_er>d_r  event  with  Status  j-  0  which  passes  the 
TEXT  field  of  the  End_Response  to  the  SAPI.  The  channel 
machine  then  enters  the  NULL  state. 


Semantics  of  Fields 


Type :  4  specifies  End. 

C/R:  0  specifies  Command. 

Credit:  is  irrelevant. 

Seq:  specifies  the  sequence 


number 


of 

the  las 

End_Command . 

of 

the  las 

re  the 

channel  wa 

to  be 

terminated 

Ack :  specifies  the  sequence  number 
Transmi t_Command  correctly  received  befc 
terminated . 


Group  and  Member:  specifies  the  channel(s) 

If  Group  is  not  zero  and  Member  is  zero,  all  channels  with  the 
same  Group  are  to  be  terminated.  If  both  Group  and  Member  are 
zero,  all  channels  are  to  be  terminated.  The  latter  option  is 
intended  as  part  of  the  restart  sequence  (see  Initializing 
Host  -  Front  End  Communication) . 

Control  The  Control  field  bits  have  the  following  meanings: 
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End  Command 


Flush  away:  (bit  1=1)  means  immediately  flush  data 
which  is  queued  going  away  from  the  sender  of  the 
End_Command  and  terminate  the  channel.  If  this  option 
is  not  requested  (i.e.,  if  bit  1=0),  the  End_Command 
is  not  to  take  effect  until  all  data  queued  going  away 
from  the  sender  of  the  End_Command  has  been  processed  in 
the  normal  manner. 


Semantics  of  TEXT 


TEXT  contains  the 


service  access  protocol 


message. 
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End_Response 


Function 

An  End_Respdnse  is  used  by  a ,  channel  machine  to  acknowledge  to 
its  apposite  that  a  channel,  group  of  channels,  or  all 
channels  have  been  terminated  as  requested  by  its  apposite. 


When  Sent 

When  an  acceptable  s_end_r  event  has  been  caused  by  an  SAPI, 
its  CPI  sends  an  End  Response. 
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c,na_Kesponse 


Sanding  States 


CURRENT  STATE 

1 

1 

INPUT 

1  NEXT  STATE 

1 

1  OUTPUT 

1 

)  COMMENT 

(SUB-STATE) 

1 

1 

1 

1 

1 

1 

NULL 

1 

acceptable 

| - -  . 

1 

1  c  accept 

1 

1 

1 

s  end  r  (from  HFP 

1 

1  End  Response 

1 

1 

Maintenance 

1 

1 

1 

Service) 

1 

1 

1 

1 

! 

NULL 

1 

End  Command 

1 

1 . 

j  .  - 

1  End  Response 

1 

1  discard 

the  message 

1 

(valid  or 

1 

1 

1 

invalid,  flushing 

1 

1 

1 

1 

or  non-flushing) 

1 

1 

1 

1 

.  1  _  __  . 

SENDER 

1 

End  Command 

1 

1  NULL 

1 

1  c  end  c 

1 

1 

PENDING 

1 

(vaTid  or 

i 

I  End  Response 

i 

1 

invalid,  flushing 

1 

1 

1 

or  non-flushing) 

1 

1 

1 

1 

1 

RECEIVER 

1 

1 

invalid 

1 

1  NULL 

1 

1  c  end  c 

t 

1  log  the 

error 

PENDIN'J 

1 

End_Command 

1 

j  End  Response 

1 

1 

SENDER 

1 

1 

valid  End  Command 

1  NULL 

1 

1  c  end  c 

1 

TAKING_BACK 

1 

i 

1  End  Response 

1 

I 

_ 1 

RECEIVER 

1 

1 

acceptable 

1  NULL 

1 

1  c  accept 

1 

TAK1NGJ3ACK 

1 

s_end_r 

1 

1  Bnd_Response 

1 

1 

RECEIVER 

1 

1 

valid  End  Command 

1 

1  NULL 

1 

1  c  end  c 

1 

taking'back 

1 

1 

1 

1 

1  End_Response 

1 

1 

ESTABLISHED 

I 

inval  id 

I  NULL 

1 . 

1  c  end  c 

1  log  the 

error 

1 

End  Command 

1 

I  End  Response 

1 

1 

(flushing  or 

I 

1 

1 

non-flushing) 

1 

1 

1 

SENDER 

DRAINING 

valid  End_Command 
(flushing) 

1 

1 

NULL 

1 

1  c_end_c 

1  End  Response 
_ i 

1 

!  discard  any  data 

1  queued 

1  _  . 

SENDER 

inval id 

"1 

1 

NULL 

1 

1  c_end_c 

'  1 

1  log  the  error 

TERMINATING 

End_Command 

1 

1  E7?d_Response 

1 

_ 1 . . . . 

RECEIVER 

acceptable 

1 

NULL 

1  c_accept 

1 

1 

TERMINATING 

s_end_r 

i 

.1 

1  End_Response 

1 

1 

RECEIVER 

valid  End^Command 

1 

NULL 

1  " 

1  c_end_c 

1 

TERMINATING 

( flushing~or 

1 

I  End_Response 

1 

non-flushing) 

1 

1 

65 


t.nci__K  espouse 


Action  When  Received 


In  the  normal  case:  a  channel  machine  receiving  an 
End_Response  is  m  either  the  SENDER_TAKING_3ACK  state  or  the 
SENDER_TERMINATING  state.  The  channel  machine  then  causes  a 
c__end_r  event  in  order  to  pass  to  the  TEXT  field  of  the 
End_Response  to  the  SAPI.  The  channel  machine  then,  enters  the 
NULL  state. 

In  case  of  error:  the  channel  machine  is  to  log  the  error  (see 
HFP  Maintenance  Service)  and,  if  appropriate,  cause  a  c  end_r 
event  in  order  to  pass  the  TEXT  field  of  the  End_Response  to 
the  SAPI.  In  either  case,  the  channel  machine  then  enters  the 
NULL  state. 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1 

1  NEXT  STATE 

1 

1 . 

1 

j  OUTPUT 

1 

1 

1 

1 

COMMENT 

NULL 

End_Response 

1 

1 . 

1 . 

1 

1 . 

1 

1 

discard  the  message 

SENDER 

valid 

1 

1  NULL 

1  c  end  r 

1 

TAKING_BACK 

End_Response 

1 

1 

1 

1 

1 

SENDER 

val  id 

"1  . 

1  NULL 

1  c  end  r 

1 

TERMINATING 

End_Response 

1 

1 

1 

1 

any  other 

End  Response 

1 - 

1 . 

1 

log  the  error 

state 

(val  id  or 

1 

1 

1 

invalid) 

1 

1 

1 

1 

1 

1 

Subsequent  Action  by  the  Receiver 
I n  the  normal  case:  none. 

In  case  of  error:  none. 

Subsequent  Action  by  the  Sender 
I n  the  normal  case :  none. 

In  case  of  error:  the  channel  machine  logs  the  error  and 
enters  the  NULL  state. 
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End_ReSponse 


Semantics  of  Fields 

Type 4  specifies  End. 

C/R:  1  specifies  Response. 

Credit:  is  irrelevant. 

Seg:  specifies  the  sequence  number  of  the  last 

Transmit_Command  sent  by  the  sender  of  the  End_Response . 

Ack:  specifies  the  sequence  number  of  the  last 

Transmi t_Command  sent  by  the  sender  of  the  End_Response . 

Group  and  Member:  specifies  the  channel(s)  referenced  in  the 
End  Command. 


Status:  indicates  whether  or  not  an  error  has  been 
encountered.  The  following  codes  are  applicable  to  the 
End__Response : 

Status  Meaning 

0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 

field  of  the  End_Command  referenced  a  channel 
machine  unknown  to  the  receiving  CPI. 

4  Option  not  implemented:  a  Control  field  option 

was  specified  in  the  End_Command  which  is 
legal  but  not  implemented  by  the  receiving 
CPI. 


5  Message  too  long:  the  number  of  bits  in  the 
End_Command  exceeded  the  maximum  permitted  by 
the  receiving  CPI. 

6  Service  access  protocol  message  error:  an 
error  in  the  service  access  protocol  message 
contained  in  the  TEXT  field  of  the  End_Command 
was  detected  by  the  SAPI. 

7  Illegal  Control  field  value:  the  Control 

field  of  the  End_Command  contained  an 
undefined  value. 
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End  Response 


Semantics  of  TEXT 


TEXT  contains  the  service  access  protocol  message. 
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Execute  Command 


Function 


An  Execute_Command  is  used  by  a  channel  machine  to  effect  the 
transfer  of  data  over  a  channel  to  its  apposite  without  the 
guarantees  of  flow-control  and  order  provided  via 
Transmi t_Command  (see  Overview,  Transmission  Control). 

An  SAPI  requesting  a  channel  machine  to  send  an 
Execute_Command  has  three  options: 

1.  it  may  request  that  the  Execute_Command  be  delivered 
asynchronously  vis-a-vis  the  flow-controlled ,  in- 
order  data  stream, 

2.  it  may  request  that  the  Execute_Command  be  delivered 
in  synchronization  with  a  specified  point  in  the 
flow-controlled,  in-order  data  stream; 

3.  in  either  case,  it  may  request  that  the 

Execute_Command  carry  with  it  a  request  that  its 
apposite  SAPI  be  notified  of  its  arrival. 


When  Sent 

When  an  acceptable  s_execute_c  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  an  Execute  Command. 


Sending  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  j  OUTPUT  I  COMMENT 

(SUB-STATE)  i  1|  | 


ESTABLISHED  I  acceptable  I  -----  |  c_accept  I  place 

I  s_execute_c  I  I  E>?ecute^Command  I  Execute_Command  at 

I  (synchronize)  I  I  j  end  of  send  queue 


ESTABLISHED  I  acceptable  I  -----  j  c^accept  j  place 

I  s_execute_c  I  I  Execute_Conmand  I  Execute_Comnand  at 

I  (expedite)  I  I  j  head  of~send  queue 
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Execute  Command 


v 


Action  When  Received 


In  the  normal  case: 


the  channel  machine 
in  the  ESTABLISHED 
the  channel 


recei 
state, 
machine  then 
event  in 
directly 


Execute_Command  is 
Synchronize  bit  is  not  set, 

at  the  earliest  opportunity,  a  c_execute_c 
pass  the  TEXT  field  of  the  Execute_Command 
SAPI,  i.e.,  ahead  of  any  other  data  queued  for  it 
Synchronize  bit  is  set,  the  channel  machine  will  del 
Execute_Command  at  the  point  in  the  data  stream  whe 
received.  If  the  Attention  bit  is  set,  the  SAPI  is 
immediately  via  the  a  system  specific  attention  or  ou 
signal . 


ving 

If 


an 
the 
causes , 
order  to 
to  the 
.  If  the 
iver  the 
re  it  was 
notified 
t-of-band 


In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service),  discards  the  message,  and  sends  an 
Execute_Response  with  the  Status  code  proper  to  the  error  (see 
Status  codes  for  Execute__Response  below)  . 


Receiving  States 


CURRENT  STATE 

1  1  1 

1  INPUT  1  NEXT  STATE  1  OUTPUT 

1  comment  1 

(SUB-STATE) 

1 

1 

1  1 

ESTABLISHED 

valid  1  -  - 

-  -  1  c  execute  c 

1  place  c  execute  c  at  1 

Execute  Command  1 

1  er.d  of  receive  queue  1 

(synchronize)  1 

1 

1 

1  1 

ESTABLISHED 

valid  1  -  - 

•  -  -  1  c  execute  c 

I  notify  SAPI  of  1 

Execute  Command  | 

1  attention,  place  1 

(synchronize,  1 

1 

1  c  execute  c  at  end  1 

attention)  1 

1 

1  of  receive  queue  1 

ESTABLISHED 

valid  1  -  - 

1 

-  -  -  1  c  execute  c 

1  1 

1  place  c  execute  c  at  | 

Execute  Command  1 

1  head  of  receive  1 

(expedite)  I 

.  _ _  .  (__ 

1 

1 

I  queue  1 

ESTABLISHED 

valid  1  -  - 

-  -  -  i  c  execute  c 

i  "  i 

1  notify  SAPI  of  1 

! 

Execute  Command  I 

t  *" 

t 

1  attention,  place  1 

(expedite,  1 

1 

1  c  execute  c  at  head  | 

attention)  i 

1 

1  of  receive  queue  1 

SENDER 

valid  1  -  - 

-  -  -  1  Execute  Response 

1  1 

1  acknowledge  bur  1 

DRAINING 

Execute_Command  1 

1  (Status=3») 

1  discard  the  message  1 

any  other 

1 

Execute  Command  1  -  - 

1 

1 .  1 

1  log  the  error  1 

state 

(valid  or  1 

1 

1  1 

invalid)  1 

! 

1 

1 

1  1 

1  1 

1 

I 
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Subsequent  Action  By  the  Receiver 

In  the  normal  case:  an  s_execute_r  event  with  Status  =  0  is 
caused  by  the  SAPI  in  response  to  the  c_execute  c  event.  The 
channel  machine  then  sends  an  Execute_Response  with  Status  = 
0,  and  continues  to  exchange  data  with  its  apposite. 

In  case  of  error:  a  s_execute_r  event  with  Status  i-  0  is 
caused  by  the  SAPI.  The  channel  machine  then  sends  an 
Execute_Response  with  Status  ?  0  and  resumes  data  exchange 
with  its  apposite. 


Subsequent  Action  by  the  Sender 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  if  the  channel  machine  receives  an 
Execute_Response  with  Status  j-  0,  it  notifies  the  SAPI  of  the 
error  via  a  c_execute_r  event  with  Status  f-  0  and  resumes  data 
exchange  with  its  apposite. 


Semantics  of  Fields 

Type:  3  specifies  Execute. 

C/R:  0  specifies  Command. 

Credit:  specifies  the  number  of  Transmit_Commands  beyond  the 
number  specified  by  the  Ack  field,  which  the  sender  of  the 
Transmi t_Response  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  the  last 

Transmi t_Command  sent  by  the  sender  of  the  Execute_Command . 

Ack :  specifies  the  sequence  number  of  the  last  in-sequence 
Transmi t_Command  correctly  received  by  the  sender  of  the 
present  Execute_Command . 

Group  and  Member:  specifies  the  channel  over  which  the 
Execute_Command  is  to  be  sent. 

Control :  the  Control  field  bits  have  the  following  meaning: 

Bit 

0123  Meaning 

0000  Place  the  Execute_Command  at  the  head  of  the 

data  queue. 
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Execute  Command 


1000  Place  the  Execute_Command  at  the  head  of  the 
data  queue.  Notify  the  SAPI  of  the  Attention. 


0001 

Place 

data 

the  Execute 
queue. 

Command 

at 

the 

end 

of 

the 

1001 

Place 

the  Execute 

Command 

at 

the 

end 

of 

the 

data  queue.  Notify  the  SAPI  of  the  Attention. 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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Exeeute_Response 


Function 


An  Execute  Response  is  used  by  a  channel  machine  to  effect,  the 


transfer  of  data  to 
Execute_Command .  Like 
Execute_Response  is  not 
guarantee. 


its  apposite  in  response  to  an 
the  Execute__Command ,  the 

subject  to  flow-control  and  order 


When  Sent 

When  an  acceptable  s_execute_r  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  an  Execute_Response . 


Sending  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COWNT 

(SUB-STATE)  |  II  | 


ESTABLISHED  I  acceptable  I  -----  |  c_accept  I  place 

I  s_execute_r  I  I  Execute__Responsc  I  Execute_Response  at 

I  II  I  heart  of~senrt  queue 


SENDER_  I  valid  I  -----  |  Execute_Response  I  acknowlertqe  but 

DRAINING  I  Execute_Commanrt  I  I  (Status=39)  I  discard  the  nessaqe 


Action  When  Received 


In  the  normal  case:  a  channel  machine  receiving  an 
Execute__Response  is  in  the  ESTABLISHED  state.  The  channel 
machine  then  causes,  at  the  earliest  opportunity,  a 
c_execute_r  event  in  order  to  pass  the  TEXT  field  of  the 
Execute_Response  directly  to  the  SAPI,  i.e.,  ahead  of  any 
other  data  queued  for  it.  The  channel  machine  does  not  change 
state. 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  notifies  the  SAPI  of  the  error  via  a 
c_execute_r  event  which  also  passes  the  TEXT  field  of  the 
Execute_Response  to  the  SAPI.  The  channel  machine  does  not 
change  state. 
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Receiving  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT 

(SUB-STATE)  I  II  I 


ESTABLISHED  I  valid  I  -----  |  c_execute_r  I  place  c_execute_r  at 

I  Exocute_Response  I  I  “  I  head  of  receive 

I  ~  I  I  I  queue 


SENDER_  I  valid  |  -  -  -  -  -  |  -  -  -  -  -  |  discard  the  message 

DRAINING  I  Execute_Response  I  I  I 


any  other  I  Execute_Response  I  -  -  -  -  -  I  -  -  -  -  -  I  log  the  error 

state  I  (valid  or  I  I  I 

I  invalid)  I  I  I 


Subsequent  Action  by  the  Receiver 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error:  the  channel  machine  resumes  data  exchange 
with  its  apposite. 


Subsequent  Action  by  the  Senuet 

In  the  normal  case :  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  the  channel  machine  resumes  data  exchange 
with  its  apposite . 


Semantics  of  Fields 

Type:  3  specifies  Execute. 

C/R:  1  specifies  Response. 

Credit:  specifies  the  number  of  Transmit_Commands  beyond  the 
number  specified  by  the  Ack  field,  which  the  sender  of  the 
Transmi t_Response  is  prepared  to  receive. 

Seg:  specifies  the  sequence  number  of  the  last 

Transmi t_Command  sent  by  the  sender  of  the  Execute_Response . 

Ack:  specifies  the  sequence  number  of  the  last  in-sequence 
Transmit.  Command  correctly  received  by  the  sender  of  the 
present  Execute_Response . 
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Group  and  Member:  specifies  the  channel  over  which  the 
Execute_Response  is  to  be  sent. 

Status:  indicates  whether  or  not  an  error  has  been 
encountered.  The  following  codes  are  applicable  to  the 
Execute_Response : 


Status  Meamnc 


0  Command  was  successful. 


1  Channel  non-existent:  the  Group  and  Member 
fields  of  the  Execute_Command  referenced  a 
channel  machine  unknown  to  the  receiving  CPI, 

2  Illegal  state:  the  Execute_Command  referenced 
a  channel  machine  which  was  in  a  state  for 
which  the  Execute_Command  is  an  illegal  input. 

3  Command  not  implemented:  the  Execute_Command 
is  not  implemented  by  the  receiving  CPI. 

5  Message  too  long:  the  number  of  bits  in  the 
Execute_Command  exceeded  the  maximum  permitted 
by  the  receiving  CPI. 

6  Service  access  protocol  message  error:  an 
error  in  the  service  access  protocol  message 
contained  in  the  TEXT  field  of  the 
Execute_Command  was  detected  by  the  SAPI. 

7  Illegal  Control  field  value:  the  Control  field 
of  the  Execute_Command  contained  an  undefined 
value . 

39  Command  discarded:  the  channel  machine  is  in 

the  SENDERJJRAINING  or  SENDRRJTERMINATING 
state,  and  has  discarded  the  Execute_Command 
without  passing  it  to  the  service  access 
level . 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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NOP 


Function 

A  NOP  is  used  by  a  channel  machine  as  a  Ciller  when  a  channel 
protocol  message  does  not  completely  fill  a  link  level 
protocol  frame. 


When  Sent 

When  a  channel  protocol  message  does  not  completely  fill  a 
link  protocol  frame,  the  channel  machine  may  send  a  NOP  as 
filler . 


Sending  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

|  NEXT  STATE 

1 

1  OUTPUT 

1 

1  COMMENT 

1 

any  state 

any  input 

1 . 

1 

'  1 

1  NOP 

1 

I 

1 

Action  When  Received 

In  the  normal  case:  the  channel  discards  the  NOP. 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 
( 

1  OUTPUT 

1 

1 

|  COMMENT 

1 

any  stste 

NOP 

1 . 

1 . 

1 

1  discard 
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Transmit  Command 


Function 

A  Transmi t_Command  is  used  by  a  channel  machine  to  effect  the 
flow-controlled,  in-order  transfer  of  data  to  its  apposite 
(see  Overview,  Transmission  Control). 


When  Sent 

When  an  acceptable  s_transmi t__c  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  a  Transmit_Command  (flow- 
control  permitting)  . 


Action  When  Received 

In  the  normal  case:  a  channel  machine  receiving  a 
Transmi t_Command  is  in  either  the  ESTABLISHED  state  or  the 
RECEIVERJDRAINING  state.  The  channel  machine  then  causes  a 
c_transmit_c  event  in  order  to  pass  the  TEXT  field  of  the 
Transmi t_Command  to  the  SAPI.  The  channel  machine  does  not 
change  state,  but  does  apply  the  transmission  control 
discipline  (see  Transmission  Control).  Transmit_Commands  may 
also  be  received  in  the  RECEI VER_TERMINATING  state  after  a 
non-flushing  End_Command  has  been  received.  (see  Termination, 
End_Command) . 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  discards  the  message,  and  sends  a 
Transmi t_Response  with  the  Status  code  proper  to  the  error 
(see  Status  for  Transmit_Response  below). 
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Receiving  States 


j  1 

CURRENT  STATE 
(SUB-STATE) 

1  II 

1  INPUT  1  NEXT  STATE  I  OUTPUT 

1  1  1 

1  _ 1 _ _ 1  ...... 

1  COMMENT 

1 

1  1" 

! 

!  1 

! 

ESTABLISHED 
(with  data 
queued  for 
apposite 

CPI) 

1  valid  1  - 

I  Transmit  Command  I 

1  1 

1  1 

1  1 

1  1 

1 

-  -  |  c_transmit_c 

1  Transmi t_Command (s) 

1 

1 

1 

I  update  flow  control 

1 

1 

1 

1 

1 

1 

ESTABLISHED 
(with  no 
data  queued 
for 

apposite 

CPI) 

1  1 

1  valid  1  -  -  - 

1  Transmit_Command  1 

1  1 

1  1 

1  1 

1  1 

-  -  j  c_transmit_c 

1  T7ansmit_Response 

1 

1 

1 

1 

1  update  flow  control 

1 

1 

1 

1 

1 

1 

1 

1 

I 

ESTABLISHED 

1  1 

1  invalid  1  -  -  - 

I  Transmit  Command  | 

1  “  1 

1 

-  -  1  Transmi t_Response 

1  (Statuses) 

1 

1  log  the  error 

1 

1 

1 

1 

1 

SENDER 

DRAINING 

1  1 

I  valid  I  -  -  - 

I  Transmit_Command  I 

1  1 

-  -  I  Transmi t_Response 

1  (Status°39) 

1 

1  acknowledge  but 

1  discard  any  incominq 

1  messages 

1 

1 

1 

SENDER 

DRAINING 

1  1 

I  invalid  1  -  -  - 

1  Transmi t_Command  1 

-  -  1  Transmi t_Response 

1  (Statuses) 

1 

1  log  the  error 

1 

1 

1 

1 

SENDER 

TERMINATING 

1  i 

1  valid  1  -  -  - 

I  Transmit_Command  1 

1 

1  discard  the  message 

1 

1 

1 

I 

any  other 
state 

r .  . i . 

1  Transmi t_Command  1  -  -  - 

I  (valid  or  1 

1  invalid)  1 

1  1 

1 

1 

1 

I  log  the  error 

1 

1 

1 

Subsequent  Action  by  the  Receiver 

In  the  normal  case :  the  channel  machine  acknowledges  its 
receipt  of  the  Transmit_Command  via  the  Ack  field  of  the  next 
Command  or  Response  it  sends,  and  does  not  change  state,  when 
flow  control  credit  must  be  extended  and  the  channel  machine 
has  no  other  messages  to  send,  it  sends  a  Transmit_Response. 

In  case  of  error:  the  channel  machine  sends  a 

Transmi t_Response  with  Status  i-  0  but  does  not  change  state. 
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Subsequent  Action  by  the  Sender 


In  the  normal  case:  as  long  as  the  channel  machine  has  data  to 
send  and  flow  control  permits,  the  channel  machine  continues 
to  exchange  data  with  its  apposite. 

In  case  of  error:  the  channel  machine  logs  the  error  and  takes 
the  appropriate  action,  resuming  data  exchange  with  its 
apposite. 


Semantics  of  Fi elds 

Type:  1  specifies  Transmit. 

C/R:  0  specifies  Command. 

Credit:  specifies  the  number  of  TransmitjSommands  beyond  the 
number  specified  by  the  ACK  field,  which  the  sender  of  the 
Transmi t_Command  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  this  Transmit_Command . 

Ack :  specifies  the  sequence  number  of  the  last  in-sequence 
Transmi t^Command  correctly  received  by  the  sender  of  the 
present  Transmi t_Command . 

Group  and  Member :  specifies  the  channel  over  which  the 
Transmi t^Command  is  to  be  sent. 

Control  The  use  of  this  field  is  undefined. 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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Transmi t_Response 


Function 


A  Transmi t_Response  is  used  by  a  channel  machine  to 
transmission  control  information  to  its  apposite  (e.g 
acknowledge  receipt  of  a  Transmit_Command ,  to  update 
control)  or  to  report  to  its  apposite  an  error 
Transmit  Command  received. 


pass 
. ,  to 
f  low- 
in  a 


When  Sent 

When  a  channel  machine  must  acknowledge  a  Transmi t_Command  and 
has  no  Transmit_Commands  to  send,  or  when  an  error  has  been 
detected  in  the  Transmit_Command ,  or  when  flow-control  Credit 
(see  Transmission  Control)  must  be  extended  and  the  channel 
machine  has  no  other  messages  to  send,  it  sends  a 
Transmi t_Response. 


i 

t 

l 

t 


Sending  States 


i 


i 


CURRENT  STATE 
(SUB-STATE) 


INPUT 


NEXT  STATE 


OUTPUT 


COMMENT 


ESTABLISHED  I  valid 

(with  no  I  Transmit_Command 

data  queued  I 


c_transmit_c 
T7ansmi t_Response 


update 


flow  control 


for 

apposite 

CPI) 


ESTABLISHED 


inval  id 

Transmit  Command 


Transmi t_Response 
(Status^O) 


log 


the  error 


SENDER 

DRAINING 


valid 

Transmi t_Command 


Transmit  Response 
(Status=5'9) 


acknowledge  but 
discard  any  incoming 
messages 


SENDER 

DRAINING 


inval  id 

Transmit  Command 


Transmi t_Response 
(Statuses) 


log  the  error 
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Action  When  Received 

In  the  normal  case:  a  channel  machine  receiving  a 
Transmi t_Response  is  in  either  the  ESTABLISHED  state,  the 
SENDER_DRAINING  state,  or  the  SENDER_TERMINATING  state.  The 
channel  machine  does  not  change  state,  but  does  apply  the 
transmission  control  discipline  (see  Transmission  Control). 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  and  performs  any  necessary  error- 
recovery,  but  does  not  change  state.  If  the  error  was 
"message  out  of  order"  (Status  =  35) ,  the  channel  machine  is 
to  retransmit  all  messages  up  to  and  including  the  last 
message  sent. 


Subsequent  Action  By  the  Receiver 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  the  channel  machine  resumes  data  exchange 
with  its  apposite. 


82 


Transmit  Response 


sequent  Action  by  the  Sender 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  the  channel  machine  resumes  data  exchange 
with  fts  apposite.  (If  the  channel  machine  encounters  a  high 
frequency  of  erroneous  Transmit_Commands  some  special  action 
may  be  required.) 


Semantics  of  Fields 

Type:  1  specifies  Transmit. 

C/R:  1  specifies  Response. 

Credit:  specifies  the  number  of  Transmit_Commands  beyond  the 
'.lumber  specified  by  the  Ack  field,  which  the  sender  of  the 
Transmi t_Response  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  the  last 

Transmi t_Command  sent  by  the  sender  of  the  Transmi t_Response . 

Ack :  specified  the  sequence  number  of  the  last  in-sequence 
Transmi t_Command  correctly  received  by  the  sender  of  the 
present  Transmi t_Response. 

Group  and  Member :  specifies  the  channel  over  which 

Transmi t_Response  is  to  be  sent. 

Status:  indicates  whether  or  not  an  error  has  been 
encountered.  The  following  codes  are  applicable  to  the 
Transmi t_Response : 

Status  Meaning 

0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 
fields  of  the  Transmit_Command  referenced  a 
channel  machine  unknown  to  the  receiving  CPI. 

2  Illegal  state:  the  Transmi t_Command  has 

referenced  a  channel  machine  which  was  in  a 
state  for  which  the  Transmi t_Command  is  an 
illegal  input. 

5  Message  too  long:  the  number  of  bits  in  the 

Transmit_Command  exceeded  the  maximum 
permitted  by  the  receiving  CPI. 
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6  Service  access  protocol  message  error:  an 

error  in  the  service  access  protocol  message 
contained  in  the  TEXT  field  of  the 

Transmit_Command  was  detected  by  the  SAPI. 

35  Out  of  sequence:  a  Transmit_Command  was 
received  and  discarded  whose  Seq  field  was 
neither  in  sequence  [equal  to  Clast  received> 
+  1]  nor  a  duplicate  [between  (Clast  received> 

7)  and  Clast  received>  inclusive]  (see 
Transmission  Control)  . 

36  Out  of  window:  a  Transmi t_Command  was  received 

and  discarded  whose  Seq  field  was  between 
(Clast  received>  +  Credit  +  1)  and  (Clast 

received>  +  8)  inclusive  (see  Transmission 

Control) . 

39  Command  discarded:  the  channel  machine 

received  a  Transmi t_Command  or  an 
Execute_Command ,  is  in  the  SENDER_DRAINING  or 
SENDER_TERMINATING  state,  and  has  discarded 
the  Command  without  passing  it  to  the  service 
access  level. 


Semantics  of  TEXT 


undefined 


Field 


Function 


Size 


Type 


C/R 


Credit 


Seq 


Ack 


Service 


Group 


Member 


specifies  the  number  of  bits  in  the 
entire  message. 


specifies  the  message  type: 


Begin  0 
Transmit  1 
Execute  3 
End  4 
Nop  S 


(C/R  =  0)  indicates  a  Command  or 
a  (C/R  -  1)  indicates  a  Response. 


specifies  the  number  of 
Transmit^ Commands  beyond  the  number 
specifieS  by  the  Ack  field,  which 
the  sender  of  this  message  is 
prepared  to  receive. 


specifies,  in  a  Transmit_Command 
its  sequence  number. 


specifies  the  sequence  number  of 
the  last  in-sequence 
Transmit_Command  correctly  received 
by  the  sender  of  this  message. 


Field 

Sane 

HEADER 

Size 

Type 

C/R 

Credit 

Seq 

Ack 

(not  used) 
Group 

Member 

Control 

(Connands) 

PAD 

TEXT 


Field 

Size 

(bits) 

/ - \ 

I  1 

I  16  I 


3 
1 

4 
4 
4 
4 

12 


16 


8 

No. 4  A 


Note  B 


Message  Format 


Alternate 

Field 

Size 

(bits) 


A1 ternate 

Field 

Nano 


8  I  Service 

i  (BEGIN  Command) 


I . I 

I  8  |  Status 

j  I  (Responses) 


Note  A:  The  size  of  PAD  is  an  Installation  parameter. 
Note  B:  The  size  of  TEXT  is  computed  by: 

(Size)  -  (size  of  PAD)  -  72. 


specifies,  in  BeginjCommand ,  the 
SAPI  to  which  the  channel  is  to  be 
established. 


Control  specifies  control  information  for 
Execute_Commands  and  End_Commands . 


specifies  the  channel  group  which 
the  message  references. 


specifies  the  channel  which  the 
message  references  within  the 
channel  group. 


Status  specifies  status  information  in 
Responses. 


PAD  is  zero  or  more  bits  long  and 

serves  only  to  place  TEXT  on  a 
convenient  boundary. 


TEXT  contains  a  service  access  or  other 

higher  level  protocol  message. 


Channel  Protocol  Header 


A  CPI  SENDS 

A  CPI  SENDS 

Begin  Command 

to  initiate  a  new  connection. 

Bcgin^Response 

to  acknowledge  a  Begin_Command. 

End_Command 

to  terminate  a  connection. 

Er.d_Rooponse 

to  acknowledge,  an  End__Cornmand . 

Execute__Cornmand 

to  send  out-of-band  signals. 

Execute_Response 

to  acknowledge  an  ExecutejSomand. 

Transmit_Con«r.and 

to  send  data  between  the  host  and  the 
front  end. 

Tran  smi  t__Re  spons  e 

to  acknowledge  one  or  more  Tran smi  ^Commands. 

An  SARI  causes 

A  CPI  CAUSES 

sjbcglnjc 

to  request  that  a  new  connection  be 
established. 

cjtccept 

~  to  notify  the  SAPI  that  an  s_<evcnt>  appeared  correct 
and  has  been  acted  on. 

sjbegin_r 

to  respond  to  a  new  request  for  sorvico 
by  a  cjbeginjc. 

c_begin_c 

to  request  a  new  service  be  initiated. 

Sjend  c 

to  request  that  a  connection  be  terminated. 

cj>cgin_r 

to  acknowledge  a  request  for  new  service  by  an 
s_begin_c. 

s_end_r 

to  respond  to  a  request  to  terminate  a 
servlco  by  a  c_end_c. 

cjmdjB 

to  request  a  service  for  a  user  be  terminated. 

s_execute_c 

to  request  that  an  out-of-band  signal 
be  sent. 

o_ond_r 

to  acknowledge  a  request  for  termination  by  an 
s_end_c. 

s_executo_r 

to  respond  to  an  out-of-band  signal  delivered 
by  a  c_execute_c. 

e_axecuto_c 

to  deliver  an  out-of-band  signal  to  the  SAPI. 

s_ identify 

to  notify  the  CPI  that  a  service  is  ready 
to  accept  users. 

c_jBxecuto_r 

to  acknowledge  an  out-of-band  signal  gonerated  by 
an  sjQxecutojs. 

sjready 

to  control  the  flow  of  data  from  the  CPI  to 
the  SAPI. 

ejeeady 

to  control  the  flow  of  data  from  tho  SAPI  to  the  CPI. 

s_status 

**  to  request  the  status  of  the  CPI  for 
a  particular  connection. 

c_roject 

to  notify  tho  SAPI  that  an  sj£event>was  in  error. 

s_transmitjc 

to  request  that  data  be  sent. 

C_8tatU8 

to  provide  the  SAPI  with  the  status  of  a  connection 
in  response  to  an  s_status. 

c__transmit_c 

~  to  deliver  data  to  the  SAPI 

A  Synopsis  of  Commands, 
and  Channel  Interface 


Responses 

Events 


Host  Front  End  Protocol 
Channel  Machine 
State  Table 


This  section  contains  the  detailed  state  transition  table  for  CPI 
channel  machines.  There  is  a  channel  machine  for  each  channel. 
A  given  channel  machine  receives  inputs  from  and  generates 
outputs  for  both  the  CPI  multiplexor/demultiplexor  (Commands  and 
Responses)  and  an  SAPI  (events) . 
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Channel  Machine  States 


1  CURRENT  STATE 

1 

INPUT 

I  NEXT  S"ATE 

1  OUTPUT 

1  COMMENT 

(SUB -STATE) 

1 

1 

1 

1 

t 

1 

1 

NULL 

1 

1 

acceptable 

1 

1  SENDER 

1 

1  c  accept 

1 

1  initialize  channel 

1 

1 

s  begin_c 

1  PENDING 

1  Begin  Command 

1 

1  machine 

1 

NULL 

1 

1 

acceptable 

1 

| - 

1 

1  c  accept 

1 

1 

1 

s  end  c 

1 

1  End  Command 

1 

1 

(flue'  ng,  from 

1 

1  (flushing) 

1 

1 

HFP  Ma  'tenance 

I 

1 

1  Service) 

1 

1 

1 

I 

NULL 

1 . 

1  acceptable 

1  s_end_r  (from  HFP 

1  Maintenance 

1  Service) 

1 

| - 

1 

1 

1 

1 

I  c_accept 

I  .End  Response 

1 

1 

1 

1 

1 

1 

NULL 

1  acceptable 

I  s_identify 

1 . 

1 

1  c  accept 

1 

|  register  the  RAPI 

1 

1  . 

-  ....  ..  an. 

NULL 

1  acceptable 

1  s_status 

1 . 

1 

I  c_status 

( 

1  determine  status 

1 

NULL 

I  any  other  event 

1  (acceptable  or 

1  unacceptable) 

1 . 

1 

1 

I  c_reject 

1 

1 

i  log  the  error 

1 

1 

NULL 

1  valid 

1  RECEIVER 

1  c  begin  c 

1  initialize  channel 

1  E:=gin_Command 

1  PENDING 

1 

1 

1  machine 

1 

NULL 

11 '  1  " . 

1  End__Command 

1  (valid  or 

1  invalid,  flushing 

1 . 

1 

1 

I  End_Response 

1 

’"I . 

1  discard  the  message 

1 

1 

1  or  non-flushing) 

1 

1 

1 

1 

1 

NULL 

1  End_Response 

| - 

|  . 

1  discard  the  message 

NULL 

1 

1  any  other  Command 

| - 

1  corresponding 

1  log-  the  error 

1  (valid  or 

1 

1  Response  (Status=2)  I 

1  invalid) 

...  _l 

1 

1 

1 

1 

1 . 

1 

1 

...1 . . . 

1 

f 


NULL 


any  other 
Response  (valid 
or  Invalid) 


log  the  error 


Channel  Machine  States 


CURRENT  STATE  1  INPUT 
(SUS-STATE)  | 

1 

1  NEXT  STATE 

f 

1  OUTPUT 

1  COMMENT 
i 

_  1 

SENDER 

PENDING 

j  acceptable 

1  s_end__c  (flushing 

1  or  non-flushing) 

1 

1  SENDER 
!  TAKING  BACK 

1 

1  c_accept 

1  End_Command 

1  (flushing) 

1 

1 

1 

1 

1 

SENDER 

PENDING 

1 

1  acceptable 

1  s  status 

1  “ 

I 

| - 

i 

1 

1  c_status 

‘  1  "  . . 

1  determine  status 

1 

SENDER 

PENDING 

1 

!  any  other  event 
i  (acceptable  or 

1  unacceptable) 

1 

1 

1 . 

1 

1 

1 

1  c_reject 

1 . 

1  log  the  error 

1 

1 

1  - 

SENDER 

PENDING 

1  valid 

1  Begln_Response 

I  (Status=nj 

1 

1  ESTABLISHED 

1 

1 

1 

1  c_begin_r 

1  (Status=0) 

1 . 

1 

1 

1 

1 

SENDER 

PENDING 

1  valid 

1  Begln_Response 

1  (Statuses) 

1 

1  NULL 

1 

1 

1  c_begin_r 

1  (Status^) 

i . 

i 

i 

■ 

SENDER  I  invalid  |  SENDER_  I  c  begin  r  I  log  the  error 

PENDING  I  Begin_Response  I  TERMINATING  I  (Status?0)  I 

I  I  I  End_Command  ! 

I  I  I  (flushing)  1 


SENDER_  |  End  Command  I  NULL  I  c_end_c 

PENDING  I  (valid  or  I  I  End_Response 

I  invalid,  flushing  1  I 

I  or  non-flushing)  I  ! 


SENDER_  I  any  other  Command  I  -----  |  corresponding  I  log  the  error 

PENDING  1  (valid  or  I  I  Response  (Status®?)  I 

I  Invalid)  1  I  I 


SENDER_  I  any  other  I  -  -  -  -  -  I  -  -  -  -  -  I  log  the  error 

PENDING  I  Response  (valid  1  I  I 

I  or  invalid)  I  I  I 
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Channel  Machine  States 


1 

CURRENT  STATE  I  INPUT 

1  NEXT  STATE 

1  OUTPUT 

i 

COMMENT 

(SUB-STATE) 

1 

1 

1 

i 

RECEIVER 

I  acceptable 

1 

1  ESTABLISHED 

1 

1  c  accept 

i 

i 

PENDING 

1  s  begin  r 

1 

1  Begin  Response 

i 

J 

I  (Status=0) 

1 

1  (Status=0) 

i 

RECEIVER 

1  acceptable 

1  NULL 

1  c  accept 

i 

PENDING 

1  s  beqin  r 

1 

1  Begin  Response 

i 

I  (Status/0) 

1 

1 

1  (Status/0) 

i 

RECEIVER 

1 

1  acceptable 

1  NULL 

1  c  accept 

i 

i 

PENDING 

1  s  end  c  (flushing 

1 

1  End  Command 

i 

1  or  non-flushing) 

1 

1 

1  (flushing) 

1 

i 

1 

RECEIVER 

1  acceptable 

1 . 

1  c  status 

i 

1 

determine  status  1 

PENDING 

I  s_status 

1 

1 

i 

i 

RECEIVER 

1  any  other  event 

| - 

1  c  reject 

i 

log 

the 

error  1 

PENDING 

I  (acceptable  or 

1 

i 

1  unacceptable) 

1 

1 

i 

RECEIVER 

I  valid  End  Command 

1  RECEIVER 

1  c  end  c 

i 

PENDING 

1  TAKING_BACK 

i 

RECEIVER 

|  invalid 

1  NULL 

1  c  end  c 

i 

log 

the 

error  1 

PENDING 

I  End_Command 

! 

1  End_Response 

i 

RECEIVER 

1  any  other  Command 

1 . 

1  corresponding 

i 

log 

the 

error  1 

PENDING 

1  (valid  or 

1 

1  Response  (Status=2) 

i 

I  invalid) 

1 

1 

1 

1 

1 

i 

i 

RECEIVER 

1  any  other 

| - 

1 . 

i 

log 

the 

error  1 

PENDING 

I  Response  (valid 

1 

1 

i 

1  or  invalid) 

1 

1 

i 

Channel  Machine  States 


CURRENT  STATE 
(SUB -STATE) 

INPUT 

1 

|  NEXT  STATE 

1 

1 

1  OUTPUT 

1 

1 

1  COMMENT 

1 

SENDER 

TAKING_BACK 

acceptable 
s_end_c  (flushing 
oF  non-flushing) 

| - 

1 

1 

1 

1 

i  c_accept 

1  End  Command 

1  (flushing) 

1 

1 

1 

1 

1 

1 

SENDER 

TAKINGJSACK 

acceptable 

s_status 

| - 

1 

1 

1  c_status 

1 

1  determine  status 
( 

1 

SENDER 

TAKING_BACK 

any  other  event 
(acceptable  or 
unacceptable) 

| - 

1 

1 

1 

1  c_rejcct 

1 

i 

1  log  the 

1 

1 

1 

error 

SENDER 

ta;:ing_back 

val  id 

Beg ln_Response 
(Status=0) 

1 . 

1 

1 

1 . 

1 

1 

1 

1 

1 

1 

SENDER 

TAKING_BACK 

valid 

Begin_Response 

(Status/0) 

1  NULL 

1 

1 

1  c_begin_r 

1  (Status?3) 

1 

— ! . 

1 

1 

1 

SENDER 

TAKING_BACK 

valid  End_Command 

1  NULL 

1 

1 

1  c_end_c 

1  End_Response 

1 

1 

1 

SENDER 

TAKING_BACK 

valid 

End_Response 

1  NULL 

1 

1 

I  c_end_r 

1 

1 

SENDER 

TAKING_BACK 

any  other  Command 
(valid  or 
invalid) 

1 . 

1 

1 

1 

1  1 

1  send  corresponding  1  log  the 

1  Response  (Status>>2)  I 

1  1 

1  ! 

error 

SENDER 

TAKING  BACK 

any  other 

Response  (valid 
or  invalid) 

| - 

1 

1 

1 . 

1 

1 

i  log  the 

1 

1 

1 

error 

Channel  Machine  States 


CURRENT  STATE 

INPUT 

1  NEXT  STATE 

1  OUTPUT 

1 

COMMENT 

1 

(SUB-STATE) 

1 

1 

1 

1 

RECEIVER 

acceptable 

1 

1 . 

1 

1  c  reject 

1 

1 

1 

1 

TAKING  BACK 

s  beqin  r 

1 

1 

1 

(Status=0) 

1 

1 

1 

1 

1 

RECEIVER 

acceptable 

1  NULL 

1  c  accept 

1 

1 

TAKING  BACK 

s  beqin  r 

1 

1  Begin  Response 

1 

1 

(Status/0) 

1 

1  (Status/0) 

1 

1 

1 

1 

RECEIVER 

acceptable 

1 

1  NULL 

1  c  accept 

1 

1 

TAKING  BACK 

s  end  c  (flushinq 

1 

1  End  Command 

1 

1 

or  non-flushing) 

1 

1  (flushing) 

1 

1 

1 

1 

RECEIVER 

acceptable 

1  NULL 

1  c  accept 

1 

1 

TAKING_BACK 

s_end_r 

1 

1 

1  End_Response 

1 

1 

1 

1 

RECEIVER 

acceptable 

| - 

1  c  status 

1 

1 

determine  status  1 

TAKING_BACK 

s_status 

1 

1 

RECEIVER 

any  other  event 

| - 

1  c  reject 

1 

log  the 

error  1 

TAKING  BACK 

(acceptable  or 

1 

1 

unacceptable) 

1 

1 

1 

1 

1 

RECEIVER 

valid  End  Command 

1  NULL 

1  c  end  c 

1 

TAKING_BACK 

1 

1  £nd_Response 

1 

1 

RECEIVER 

any  other  Command 

1 . 

1  corresponding 

( 

log  the 

error  I 

TAKING  BACK 

(valid  or 

1 

1  Response  (Status»2) 

1 

inval id) 

1 

1 

1 

RECEIVER 

any  other 

1  RECEIVER 

1 . 

1 

log  the 

error  I 

TAKING  BACK 

Response  (valid 

1  TAKING  BACK  1 

1 

or  invalid) 

1 

1 

1 

1 

1 

1 
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Channel  Machine'  States 


CURRENT  STATE 
(SUB-STATE) 


NEXT  STATE 


ESTABLISHED 


acceptable 
s  end  c 
(IlusTiing) 


SENDER_ 

TERMINATING 


c_accept 

£rid_Command 

(flushing) 


discard  any  queued 
data 


ESTABLISHED 
(with  data 
queued  for 
apposite 
CPI) 


acceptable 
s  end  c  (non- 
fTushTng) 


SENDER 

DRAINING 


c  accept 


discard  any  data 
queued  for  SAPI; 
send  data  to 
apposite  CPI;  place 
End_Coramand  (non¬ 
flushing)  at  end  of 
send  queue; 
acknowledge  but 
discard  any  incoming 
messages 


ESTABLISHED 
(with  no 
data  queued 
for 

apposite 

CPI) 


acceptable 
s_end  c  (non- 
fTushTng) 


SENDER_ 

TERMINATING 


c_accept 

End_Command  (non¬ 
flushing) 


discard  any  data 
queued  for  SAPI; 
acknowledge  but 
discard  any  incoming 
messages 


ESTABLISHED 


acceptable 

s_execute_c 

(synchronize) 


c_accept 
Execute  Command 


place 

Execute_Comnand  at. 
end  of  send  queue 


ESTABLISHED 


acceptable 

y_execute_c 

(expedite! 


c_accept 
Execute  Command 


place 

Executejlonmand  at 
head  of"*send  queue 


ESTABLISHED 


acceptable 
s  execute  r 


c_accept 

Execute_Response 


place 

Execute_Uesponse  at 
head  of  send  queue 


ESTABLISHED 
(with  no 
data  queued 
for  SAPI) 


acceptable 

s_ready 


c_accept 


ESTABLISHED 
(with  data 
queued  for 
SAPI) 


acceptable 

s_ready 


c_accept 
c-transmit  c(s) 


ESTABLISHED 


acceptable 
s  status 


determine  status 


ESTABLISHED 


acceptable 
s  transmit  c 


c_accept 

Transmit  Command 


ESTABLISHED 


(able  to 
accept  duta 
from  SAPI 
or  previous 
allocation 
exhausted) 


c  ready 


ESTABLISHED 


any  other  event 
(acceptable  or 
unacceptable) 


c_re ject 


log  the  error 
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Channel  Machine  States 


CURRENT  STATE  1 
(SUB-STATE)  j 

1 

INPUT 

1 

1  NEXT  STATE 

1 . 

OUTPUT 

|  COMMENT 

ESTABLISHED  I 

valid  End  Command 

1  - •  " 

1  RECEIVER 

c  end  c 

1 

I  discard  any  data 

1 

(flushing) 

1  TERMINATING 

1  queued  for  SAPI  and 

1 

1 

1  for  apposite  CPI 

1 

ESTABLISHED  I 

valid  End  Command 

1 

1  RECEIVER 

1 

1  discard  any  data 

(with  data  1 

(non-flushing) 

1  DRAINING 

1  queued  for  apposite 

queued  for  1 

I  CPI;  place  c  end  c 

SAPI)  1 

1  at  end  of  receive 

1 

I  queue;  acknowledge 

1 

i  but  discard  any 

1 

1  incoming  messages 

1 

ESTABLISHED  I 

valid  End  Command 

1 

1  RECEIVER 

c  end  c 

1 

I  discard  any  data 

(with  no  j 

(non-flushing) 

1  TERMINATING 

I  queued  for  apposite 

data  queued  1 

1 

I  CPI;  acknowledge  but 

for  SAPI)  | 

I  discard  any  incoming 

1 

j  messages 

1 

ESTABLISHED  I 

invalid 

1 

1  NULL 

c  end  c 

i 

I  log  the  error 

1 

End  Command 

1 

End  Response 

1 

1 

(flushing  or 

1 

1 

1 

non-flushing) 

1 

1 

l 


ESTABLISHED 

1  valid 

1  Execute_Commaml 

1  (synchronize) 

1 

1 

I  c_execute_c 

1 

1  place  c_execute_c  at 

1  end  of  Teceive  queue 

1 

ESTABLISHED 

I  valid 

1  Execute_Command 

I  (synchronize, 

1  attention) 

1 

1 

1 

-  “  “ 

•  c_execute_c 

1 

1 

1  notify  SAPI  of 

1  attention,  place 

1  c  execute_c  at  end 

1  of  receive  queue 

ESTABLISHED 

1  Valid 

1  Execute_Command 

1  (expedite) 

1 

1 

"  “  " 

!  c_execute_c 

1 

1  place  c_executo_c  at 
|  head  of~recelve 

1  queue 

ESTABLISHED 

1  valid 

I  Execute_Command 

1  (expedite, 

1  attention) 

1 

1 

1 

~  “ 

1  c  execute  c 

1 

1 

1  notify  SAP!  of 

1  attention,  place 

1  c_execute_c  at  head 

1  o7  receive  queue 

ESTABLISHED 

1  valid 

1  Execute_Response 

1 

1 

— 

1  c_execute_r 

1 

1 

1  place  c_execute_r  at 

I  head  of“recelve 

1  queue 

1 

ESTABLISHED 
(with  data 
queued  for 
apposite 

CPI) 

1 

1  valid 

1  Transmi t_Command 

1 

1 

1 

1 

1 

1 

1 

”  “ 

1 

1  c_transmit_c 

1  Transmit  Command (s) 

1 

1 

1 

1  update  flow  control 

1 

1 

1 

1 

ESTABLISHED 
(with  no 
data  queued 
for 

apposi  te 

CPI) 

! 

1  valid 

1  Transmi t_Command 

1 

1 

1 

i 

1 

1 

1 

1 

1 

""1 

1  c_transmit_c 

1  T7ansmit_Response 

1 

1 

1 

1 

1  update  flow  control 

1 

1 

I 

I 

1 

ESTABLISHED 

I  invalid 

1  Transmi t_Command 

1 

-  -  - 

"”"l 

1  Transmi t_Responsc 

1  (Statuses) 

1 

|  Irg  tin'  i't>  : * 

1 

ESTABLISHED 

I  valid 

1  Transmi  ^Response 

I 

— 

1 

1 

t 

i  suiate  flow  control; 

1  log  any  error 

ESTABLISHED 

1' 

i  any  other  Command 

1  (valid  or 

I  invalid) 

I 

1 

! 

-  - 

) 

!  i  >u>Tpanding 
)  Ko.panse  (Status=2) 

1 

!  _  ... 

1  log  the  error 

1 

1 

ESTABLISHED 


any 

r  ' 

•  li  i  >/ 


log  the  error 


Channel  Machine  Slates 


CURRENT  STATE 
(SUB-STATE) 


SENDER_ 

DRAINING 


SENDER 

DRAINING 


SENDER 

DRAINING 


SENDER_ 

DRAINING 


SENDER_ 

DRAINING 


SENDER_ 

DRAINING 


SENDER 

DRAINING 


SENDER 

DRAINING 


SENDER_ 

DRAINING 


SENDER_ 

DRAINING 


SENDER_ 

DRAINING 


DRAINS NG 


acceptable 

s_end_c 

(flushing) 


acceptable 
s  status 


any  other  event 
(acceptable  or 
unacceptable) 


valid  End_Command 
(flushing! 


valid 

Execute  Command 


val  id 

Execute_Response 


val  id 

Transmit  Command 


(acknowledgement 
of  last  Transmit_ 
Command 


inval id 

Transmit  Command 


valid 

Transrait__Hcspon::o 


any  •‘Ikri  * 
IVAt  i.l  .  r 

'  ’’.ll  J*i) 


any  other 
Response  (valid 
or  invalid) 


NEXT  STATE 


SENDER_ 

TERMINATING 


SENDER 

TERMINATING 


c_accept 

End_Command 

(flushing) 


c_reject 


c_end_c 

End_Response 


Execute_Response 

(Status=39) 


Transmi t_Response 
(Status“39) 


End_Coranand  (non¬ 
flushing) 


Transmit  'Sr-gs-ti.-sr* 
Csss  At 


discard  any  queued 
data 


determine  status 


I  log  th 


discard  any  data 
queued 


acknowledge  but 
discard  the  message 


I  discard  the  message 


acknowledge  but 
discard  any  incoming 
messages 


corresponding 
Response  (Status=2) 


log  the  error 
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Channel  Machine  States 


CU SPENT  STATE 

1  INPUT 

1  NEXT  STATE 

1 

OUTPUT 

1 

1 

COMMENT 

(SUB-STATE) 

1 

i 

1 

» 

RECEIVER 

(  acceptable 

1  NULL 

1 

1 

c  accent 

I 

t 

»!  I < 

DRAINING 

1  s  end  c  (flushing  1 

i  End  CoBsand 

t 

I  or  non-flushing) 
1 

• 

i 

(flushing! 

S 

RECEIVER 

l 

!  acceptable 

T 

f 

f 

r  re  -«**•! 

i 

1 

discard 

the  message 

DRAINING 

I  s  execute  c 

1  " 

1 

1 

3 

I 

1 

RECEIVER 

1 

1  acceptable 

i 

••  reject 

1 

discard 

the  message 

DRAINING 

j  s  execute  r 

1 

1 

? 

2 

i 

I 

1 

1 

•RECEIVER 

i 

i 

i - 

1 

c  accept 

1 

DRAINING 

|  je  S  •*>  *  4 

I 

1 

c  transmit  c 

1 

(with  J 

go?'1'-1 

•sum 

i 

t 

i 

1 

1 

1 

1 

1 

[ 

1 

1 

1 

( 

1 

i 

DECEIVER 

1  acceptable 

i - 

! 

c  status 

1 

determine  status 

DRAINING 

1  s_stacus 

1 

1 

1 

1 

1 

1 

RECEIVER 

1 

1  acceptable 

1 - 

1 

1 

c  reject 

1 

1 

discard 

the  message 

DRAINING 

1  s_transmit_c 

1 

1 

1 

RECEIVER 

1  (last 

1  RECEIVER 

1 

c  end  c 

1 

DRAINING 

1  c_transmlt_c 
j  passed) 

1  TERMINATING 

1 

1 

1 

1 

1 

1 

1 

RECEIVER 

1 

I  any  other  event 

'1  " 

1 . 

1 

c  reject 

1 

log  the 

error 

DRAINING 

1  (acceptable  or 

1  unacceptable) 

1 

1 

1 

1 

i 

1 

RECEIVER 

i  I 

I  valid  End_Conmand  i  P.ECEIVER_ 

1 

c  end  c 

1 

discard 

any  data 

DRAINING 

I  (flushing) 

1  _  _  ___  . 

1  TERMINATING 

1  _  _ 

1 

1 

queued 

RECEIVER 

i  i 

1  any  other  Command  1  ----- 

i 

corresponding 

1 

loo  the 

error 

DRAINING 

1  (valid  or 
j  invalid) 

1 

1 

1 

i 

i 

Response  (Status=2) 

1 

1 

RECEIVER 

1  any  other 

1 . 

i 

1 

log  the 

error 

DRAINING 

1  Response  (valid 

1  or  invalid) 

! 

i 

1 

i 

i 

i 

1 

i 
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flfKSMffi 


SENDER 

TERMINATING 


SENDER 

TERMINATING 


SENDER_ 

TERMINATING 


r 

i 

SENDER 

1 

any  other 

TERMINATING 

1 

Response  (valid 

i 

1 

1 

or  invalid) 

any  other  event 
(acceptable  or 
unacceptable) 


1 

1 

1 

SENDER 

TERMINATING 

val id  End_Command 
(flushing  or 
non-flushing) 

NULL 

c_end_c 

1 

1 

SENDER 

Inval id 

NULL 

c  end  c 

1 

TERMINATING 

End_Command 

End_Response 

1  " 

SENDER 

val  id 

NULL 

c  end  r 

1 

TERMINATING 

End_Response 

1  1 

I  SENDER  1  valid 

1  TERMINATING  1  Transmit  Command 

i . i . . 

1  1 

|  SENDER  |  valid 

I  TERMINATING  1  Transmit  Response 

1  1 

any  other  Command 
(valid  or 
Inval Id) 


I  log  the  error 


|  corresponding 
I  Response  (Status«2) 


discard  the  message 


update  flow  control 


log  the  error 


log  the  error 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

i  NEXT  STATE 

1 

1  OUTPUT 

1 

| 

1  COMMENT 
! 

1 

RECEIVER 

TERMINATING 

acceptable 
s_end_c  (flushing 
or  non-flushing) 

1 

1  NULL 

1 

1 

!  c_accept' 

I  Erid_Comrt  and 

1  (flushing) 

! 

1 

1 

1 

RECEIVER 

TERMINATING 

acceptable 

s_status 

| - 

1 

1 

1  c  status 

1 

1 

1  determine  status 

1 

RECEIVER 

TERMINATING 

acceptable 
s_end_  r 

1  NULL 

1 

1 

I  c_accept 

1  Bnd_Response 

1 

1 

1 

RECEIVER 

TERMINATING 

any  other  event 
(acceptable  or 
unacceptable) 

1 . 

1 

1 

1" 

I  c_reject 

1 

1 

1 

!  log  the  error 

1 

1 

RECEIVER 

TERMINATING 

valid  End_Comnand 

( flushing-or 

non-flushinc) 

‘ 

1  NULL 

1 

1 

1 

f  ' 

1  c_end_c 
j  End_Response 

1 

1 

1 

1 

I 


RECEIVER 

TERMINATING 

any  other  Command  1  -  - 

(valid  or  1 

invalid)  1 

1 

■  -  -  1  corresponding 

I  Response  (Status=2) 

1 

1 

1 

1 

1 

log 

RECEIVER 

*  .  ■  M  L  ,11  _L.I  j  .  ..  ,  , 

• 

Any  other  1  -  - 

1 

log 

TERMINATING 

Response  (valid  I 

1 

1 

or  Invalid)  1 

1 

1 

the  error 


the  error 
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. . . 


CHANNEL  INTERFACE 


CHANNEL  INTERFACE 


Introduction 


The  following  section  describes  a  model  for  the  channel 
interface.  The  model  is  presented  as  a  set  of  events 
corresponding  to  the  Channel  Protocol  Commands  and  Responses,  and 
a  few  events  peculiar  to  the  channel  interface.  It  is  of  no 
concern  here  whether  an  implementation  of  the  channel  interface 
follows  an  event  model  or,  say,  a  procedure  calling  model. 
However,  the  functions  of  the  model  must  be  preserved.  For  a  key 
to  the  notation  used  in  this  section  see  "Notation  and 
Nomenclature  Conventions  for  the  Channel  Machine." 

For  each  event,  there  is  a  presentation  of: 

1.  its  cause, 

2.  its  effect, 

3.  the  channel  machine  state  table  for  it, 

4.  the  semantics  of  its  fields. 

The  conventions  followed  in  the  state  tables  are  given  in  the 
introduction  to  the  Complete  Channel  Machine  State  Table. 
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c_accepfc 


c_accept 


Cause 


A  channel  machine  causes  a  c_accept  event  in  order  to  indicate 
to  the  SAPI  that  an  s_event  appeared  consistent  and  has  been 
acted  upon. 


Effect 


Any  effect  of  a  c_accept  event  on  the  SAPI  depends  heavily  on 
the  implementation. 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  " 

1  NEXT  STATE 

1 

1 

|  OUTPUT  1 

1  1 

1  1 

COMMENT 

any  state 

acceptable 

1 

1  (see  the 

I  c  accept  1 

(see  the  s_e<event>) 

s_<event> 

i  s  <event>) 

1 

1  (see  the  s  <event>)  1 

Syntax 

Ref:  FIXED ( ? ) 

Group:  FIXED  (12)  J 

Member:  FIXED(16) 


Semantics 


Ref ;  specifies  the  unique  identifier  supplied  by  the  SAPI  to 
identify  this  response  to  a  previous  s_<event>. 

Group  and  Member:  specify  the  channel  to  which  this  event 
appl ies. 


c_begin_c 


c_begin_c 


Cause 


A  channel  machine  causes  a  c_begin_c  event  in  order  to  request 
an  SAPI  to  initiate  access-  to  a  service. 


FJf  f  ect 

When  an  SAPI  receives  a  c_begin_c  event,  it  determines  whether 
or  not.  it  can  initiate  access  to  the  service  and  then  causes 
an  s_begin_r  event  indicating  the  result. 


Channel  Machine  States 


CURRENT  STATE 

1 

INPUT 

1  NEXT  STATE 

1  OUTPUT 

1  COMMENT 

(SUB-STATE) 

1 

1 

1 

1 

1 

1 

NULL 

1 

val  id 

1 

1  RECEIVER 

1 

1  c_begin_j: 

1 

1  initialize  channel 

1 

Begin_Command 

|  PENDING 

■ 

1 

1  machine 

1 

Syntax 


Group: 

FIXED (12) 

Member : 

FIXED  (16) 

Service : 

FIXED  (16) 

Text : 

VARIABLE 

Semantics 

Group  and  Member:  specifies  the  channel  to  be  established. 

Service:  specifies  the  number  of  the  SAPI  to  which  the  channel 
is  to  be  established. 

Text:  contains  the  service  access  protocol  message. 
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c_begin_r 


c_fc>egin_r 


Cause 


A  channel  machine  causes  a  c__begin_r  event  in  order  to  notify 
the  SAPI  that  it  has  received  a  Begin_Response . 


Effect 


When  an  SAPI  receives  a  c_begin_r  event  with  Status  =  3,  it 
may  proceed  to  exchange  data  with  its  apposite.  If  an  SAPI 
receives  a  c_begin_r  event  with  Status  ^  0,  it  enters  the  NULL 
state . 


Channel  Machine  States 


1  INPUT 

1  NEXT  STATE 

1 

1  OUTPUT 

1 

j  valid 

1  ESTABLISHED 

J 

1  c  beqin  r 

1  Begin  Response 

1 

1  (Status»0) 

1  (Status=0) 

1 

I 

i 

1  valid 

1  NULL 

1  c  begin  r 

I  Begin  Response 

1 

j  (Status/0) 

1  (Status/O) 

1 

1 

1  invalid 

1  SENDER 

1  c  beqin  r 

1  Begin  Response 

1  TERMINATING 

1  (Status/0) 

1 

1  End  Command 

* 

1 

1  (flushing) 

1  valid 

1  NULL 

1  c  begin  r 

I  Begin  Response 

1 

1  (Status/0) 

!  (Status/0) 

1 

1 

CURRENT  STATE 
(SUB-STATE) 


COMMENT 


SENDER 

PENDING 


SENDER 

PENDING 


SENDER 

PENDING 


log  the  error 


SENDER 

TAKING  BACK 


Syntax 

Group: 
Member : 
Status: 
Text: 


FIXED  (12) 
FIXED (16) 
FIXED (8 ) 
VARIABLE 
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Semantics 


Group  and  Member:  specify  the  channel  refered  to  in  the 
Begin_Response. 

Status:  indicates  to  the  SAPI  whether  the  attempt  to  establish 
a  channel  has  been  successful.  This  field  will  contain  one  of 
the  standard  Status  codes  (see  Complete  Status  Codes) . 

Text:  contains  the  service  access  protocol  message. 


c  end  c 


c  end  c 


Cause 


A  channel  machine  causes  a  c_end_c  event  in  order  to  pass  the 
TEXT  field  of  an  End  Command  to  the  SAPI. 


Effect 

When  an  SAPI  receives  a  c_end__c  event,  it  is  to  immediately 
terminate  the  access  to  the  service  and  cause  an  s_end_r 
event. 
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c  end  c 


Channel  Machine  States 


1 

CURRENT  STATE 

1 

INPUT 

1 

NEXT  STATE 

1  OUTPUT 

1 

COMMENT 

1 

(SUB-STATE) 

1 

1 

1 

1 

1 

1 

SENDER 

1 

End  Command 

1 

1 

NULL 

1  c  end  c 

1 

1 

PENDING 

1 

(vaTid  or 

1 

I  End  Response 

1 

1 

1 

invalid,  flushing 

1 

! 

1 

1 

or  non-flushing) 

1 

i 

i 

1 

1 

RECEIVER 

1 

1 

valid  End  Command 

1 

RECEIVER 

1  c  end  c 

i 

1 

1 

PENDING 

1 

1 

TAKING_BACK 

i 

i 

1 

RECEIVER 

1 

1 

invalid 

1 

NULL 

1  c  end  c 

i 

log  the  error 

% 

1 

PENDING 

1 

End_Co«u»and 

1 

1 

I  £nd_Res ponse 

i 

i 

« 

1 

1 

SENDER 

1 

valid  End  Conxand 

1 

NULL 

1  c  end  c 

> 

s 

s 

1 

I 

■TAK I  NG_B  ACK 

1 

1 

1 

1  fnd_S  espense 

« 

« 

s 

i 

1 

RECEIVER 

I 

1 

valid  End  Cosaand 

1 

NULL 

(  C  ear*  «’ 

I 

1 

1 

TAKING_BACK 

1 

I 

1 

S  s-ari  rf 

■ 

i 

1 

1 

1 

ESTABLISHED 

valid  End  OsamtasS 

i 

.J5-" 

*  *  *c 

I 

discard  any  data 

• 

4 

« 

I 

(  flushi-sg) 

8 

'r'«f  *£'•«- 

i 

1 

queued  for  SAPI  and 

1 

1 

X 

1 

I 

for  apposite  CPI 

1 

1 

■ 

1 

ESTABLISHED 

I 

yjjs  •-*  *  .•*rat£h& 

1 

8 

RECEIVES 

1 

discard  any  data 

1 

Ivizh 

• 

1 

CHAINING 

1 

queued  for  apposite 

1 

ewafj 

1 

1 

CPI;  place  c  end  c 

8 

a 

t 

1 

1 

at  end  of  receive 

s 

i 

1 

1 

queue;  acknowledge 

r 

I 

1 

1 

but  discard  any 

r 

S 

8 

1 

1 

i nooning  messages 

ESTABLISHED 

1 

I 

valid  End  Command 

1 

1 

RECEIVER 

I  c  end  c 

I 

1 

discard  any  data 

(with  no 

1 

(non-flushing) 

1 

TERMINATING 

1 

queued  for  apposite 

data  queued 

1 

1 

1 

CPI;  acknowledge  but 

for  SAPI) 

1 

1 

1 

discard  any  incoming 

1 

1 

1 

1 

1 

messages 

ESTABLISHED 

1 

inval id 

1 

NULL 

1  c  end  c 

1 

log  the  error 

1 

End  Command 

1 

1  End  Response 

1 

1 

(flushing  or 

1 

1 

1 

1 

non-flushing) 

1 

1 

SENDER 

1 

valid  End_Command 

1 

NULL 

1  c  end  c 

1 

discard  any  data 

DRAINING 

1 

1 

(flushing) 

1 

1 

1  End_Response 

1 

1 

queued 

RECEIVER 

1 

1 

(last 

1 

RECEIVER 

1  c  end  e 

1 

DRAINING 

1 

c  transmit  c 

1 

TERMINATING 

1 

1 

1 

passed) 

1 

1 

1 

1 

RECEIVER 

1 

1 

valid  End  Command 

1 

1 

RECEIVER 

1  c  end  c 

1 

1 

discard  any  data 

DRAINING 

1 

(flushing) 

1 

TERMINATING 

1 

queued 

SENDER 

T 

l 

val  id  End  Command 

1 

1 

NULL 

1  c  end  c 

1 

TERMINATING 

l 

(flushing  or 

1 

1 

l 

non-flushing) 

1 

1 

SENDER 

l 

l 

inval  id 

1 

1 

NULL 

1  c  end  c 

log  the  error 

TERMINATING 

l 

End_Command 

1 

1  End_Response 

1 

I 

RECEIVER 

l 

l 

valid  End  Command 

1 

NULL 

1  c  end  c 

TERMINATING 

l 

(flushing  or 

1 

1  End  Response 

1 

! 

i 

l 

non-flushing) 

1 

1 
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c  end  c  - . 


Syntax 

Group: 

Menber: 

StatWS: 

T^sss-s 


FIXED  (3) 
VARIABLE 


Senant ics 


Group  and  Member:  specify  the  channel  to  be  terminated.  If 
the  Group  is  not  zero  and  the  Member  is  zero,  all  channels 
with  the  same  group  are  to  be  terminated.  If  both  Group  and 
Member  are  zero,  all  cnannels  are  to  be  terminated. 

Status:  indicates  to  the  service  whether  or  not  the 
End_Command  was  correct.  This  field  will  contain  one  of  the 
standard  Status  codes  (see  c_reject). 

Text:  contains  the  service  access  protocol  message. 
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Cause 


A  channel  machine  causes  a  c_end_r  event  in  order  to  pass  the 
TEXT  field  of  an  End_Response  to  the  SAPI  and  to  indicate  to 
it  that  the  channel  has  been  terminated. 


Effect 


When  a  SAPI  receives  a  c__end_r  event,  it  considers  the  channel 
to  be  terminated. 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

""I . . . 

1  NEXT  STATE 

1 

1  . 

1  OUTPUT 

1 

1  COMMFNT 

1 

J 

SENDER 

TAKINGJ5ACK 

val  id 

End_Response 

1 

1  NULL 

1 

1  . 

1  c_end_r 

1 

1 

SENDER 

TERMINATING 

val  id 

End^Response 

'  1 

|  NULL 

1 

_ 1 . 

I  c  end  r 

1 

1 

1 

Syntax 

Group: 
Member : 
Status : 
Text: 


FIXED (12) 
FIXED  (16) 
FIXED  (8) 
VARIABLE 


Semantics 

Group  and  Member:  specify  ~he  channel  on  which  an  End_Response 
was  received. 

Status:  indicates  to  the  service  whether  or  not  the 

End_Response  was  correct.  This  field  will  contain  one  of  the 
standard  Status  codes  (see  c  reject) , 


ir 
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Text:  contains  the  service  access  protocol  message. 


c  execute  c 


-c_execute_c 


Cause 

A  channel  machine  causes  a  c_execute__c  event  in  order  to  pass 
the  TEXT  field  of  an  Execute  Command  to  the  SAPI. 


Effect 

When  an  SAPI  receives  a  c_execute_c  event,  it  is  to  act  on  the 
TEXT  of  the  Execute_Command  immediately  and  cause  an 
s_execute_r  event. 


Syntax 

Group; 
Member ; 
Text ; 


FIXED (12) 
FIXED (16) 
VARIABLE 


c_execute_c 


Semantics 

Group  and  Member;  specify  the  channel  on  wh 
Execute_Command  was  received'. 

Text:  contains  the  service  access  protocol  message. 
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pg**5>< 


c__ready 


c_^ready 


Cause 

A  channel  machine  causes  a  c_ready  event  in  order  to  notify 
the  SAPI  that  it  is  able  to  accept  data  from  it. 


Effect 

If  the  SAPI  has  data  queued  for  the  channel  machine,  it 
attempts  to  transfer  the  data  to  it  via  an  s_transmit_c  event, 
and,  if  necessary,  updates  the  channel  interface  flow  control 
via  an  s_ready  event. 


Channel  Machine  States 


_  ...  .  - 

CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

1  OUTPUT 

1 

1  COMMENT 

1 

ESTABLISHED 

(able  to  accept 
data  from  SAPI  or 
previous 
allocation 
exhausted) 

1 . 

1 

1 

1 

1 

1 

1 

1  c_ready 

1 

1 

1 

1 

1 

1 

1 

1 

I 

_ I  _ 

Syntax 

Group: 
Member 
Msgs : 


FIXED  (12) 
FIXED (16) 
FIXED  (8) 


Semantics 


Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 


Msgs:  specifies  the  number  of 
machine  is  currently  able 
replaces  any  previous  value. 


Transmit_Commands  the  channel 
to  accept.  The  value  of  Msgs 
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c_reject 


c_reject 


Cause 


A  channel  machine  causes  a  c_reject  event  in  order  to  notify 
the  SAPI  that  an  s_event  appeared  inconsistent  and  has  not 
been  acted  upon. 


Effect 


When  an  SAPI  receives  a  c_reject  event,  it  enters  an  error 
recovery  phase. 


Channel  Machine  States 


CURRENT  STATE 

1 

INPUT 

1  NEXT  STATE 

1  OUTPUT 

1  COMMENT 

(SUB-STATE) 

1 

1 

1 

1  .  _ 

1 

any  state 

1 

1 

(any  unacceptable 

1 

| - 

1 

!  c  reject 

1 

1  lo<i  the  error 

1 

u_<event>) 

1 

1 

1 

Syntax 

Ref: 

Group: 

Member 

Reason 


FIXED  (?) 
FIXED  (12) 
FIXED  (16) 
FIXED  (8 ) 


Semantics 


Ref:  specifies  the  unique  identifier  supplied  by  the  SAPI  to 
identify  this  response  to  a  previous  s_<event>. 

Group  and  Member:  specify  the  channel  to  v/hich  this  event 
applies. 
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c_reject 


Reason:  specifies  a  code  indicating  why  the  event  referred  to 
in  the  Ref  field  is  being  rejected.  The  reasons  for  rejecting 
an  event  are  assigned  the  following  codes: 


Reason  Meanrm 


1  Channel  non.-existent :  the  Group  and  Member 

fields  of  an  s_event  (other  than  an  s_begin_c 
or  an  s_execute_c  event)  referenced  a  virtual 
channel  unknown  to  the  receiver. 


2  Illegal  state:  an  s_event  was  received 

referencing  a  channel  which  was  in  a  state  for 
which  the  event  type  was  illegal. 

3.  Event  not  implemented:  an  s_event  was  received 

whose  type  was  legal  but  not  implemented. 
Currently  this  can  only  be  an  s_begin_c, 
s_execute_c ,  s_execute_r,  or  s_status  events. 

5  Field  too  long:  the  length  of  a  field  in  the 
s_event  exceeded  the  maximum  size  permitted  at 
the  installation. 

6  Not  used. 

7  Illegal  field  value  or  combination  of  values: 
the  values  of  a  field  in  the  s_event  referred 
to  by  the  Ref  code  contained  an  illegal  fie_d 
value  or  a  field  value  that  was  inconsistent 
-with  other  field  values  specified  by  the 
s_event. 

8  Illegal  type:  the  s_event  was  of  a  type 

unknown  to  the  CPI. 

9  Illegal  Group  and  Member:  the  s_event 

specified  a  Group  and  Member  that  is  not 
accessible  to  this  SAPI. 

10  Group(s)  terminating:  communication  is  being 
terminated  for  this  Group  or  fc-r  all  Groups. 

32  Channel  in  use:  the  channel  referenced  *?*  ihr- 

s_begin_c  event  was  already  a^i*5«s‘-S  i 

not  in  the  NULL  state) . 

33  Reserved. 


34  Reserved. 
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36 


c_r eject  ' 


No  allocation:  an  s_transmit_  c  event  has  been 
received  and  discarded  because  the  SAPI  has 
exhausted  the  flow  control  allocation  given  to 
it  via  a  c__ready  event.  * 

37  Bad  channel  polarity:  the  high-order  bit  of 

the  Group  field  in  the  s_begin_c  'had  the  wrong 
value. 


38 

Channel 

enabled. 

down: 

HFP 

communication 

is 

not 

39 

Command 

discarded : 

the  channel 

machine 

received 

a 

Transmit  Command 

or 

an 

Execute^Command,  is  in  the  SENDER  DRAINING  or 
SENDSR_TERMINATING  state,  and  has  discarded 
the  command  without  passing  it  to  the  service 
access  level. 
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c  status 


c  status 


Cause 

A  channel  machine  causes  a  c  scs^S-n-*  in  ordler  to  notify 

the  SAPI  of  the  its  stats?.*.. 


Effect 

of  a  c_status  event  on  the  SAPI  will  depend  heavily 
the  installation. 


Channel  Machine  States 


CURRENT  STATE 
(SU3-STATE) 

1  INPUT 

i 

1 

1  NEXT  STATE 

1 

1  OUTPUT 

1 

1 

1  COMMENT 

1 

any  state 

1  acceptable 

1  s_status 

1 . 

1 

1 

1  c_status 

1 

1  determine  status 

1 

1 

Syntax 

Group: 
Member : 
State: 
Snd_Msgs: 
Rcv_Msgs : 


FIXED (12) 
FIXED (16 ) 
FIXED (8 ) 
FIXED  (8 ) 
FIXED  (8 ) 


f 


Semantics 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

State :  contains  a  value  indicating  the  current  state  of  the 
channel  machine.  The  encoded  values  of  the  states  are: 

0  NULL 

1  SENDER  PENDING 
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c  status 


2  RECEIVERPENDING 

3  SENDERTAKINGBACK 

4  R£CEIV£R_TAKING_BACK 

5  ESTABLISHED 

6  SENDER_DRAINING 

7  RECEIV£R_DRAINING 

8  SEND£R_TERMINATING 

9  RECEIVERJTERMINATING 

Snd  Msgs:  contains  the  number  o£  events  the  channel  machine 
can  pass  to  the  SAPI  within  the  limits  of  the  channel 
interface  flow  control. 

Rev  Msgs:  contains  the  number  of  events  the  channel  machine  is 
able  to  accept. 
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c  transmit  c 


c  transmit  c 


Cause 


A  channel  machine  causes  a  c__transmit_c  event  in  order  to  pass 
the  TEXT  field  of  a  Transmit  Command  to  the  SAPI. 


Effect 


When  a  SAPI  receives  a  c__transmit_c  event,  it  processes  the 
data  transferred  from  the  channel  machine  and,  if  necessary, 
updates  the  channel  interface  flow-control  via  an  s_ready 
event. 


Channel  Machine  States 


CURRENT  STATE 
(SUP-STATE) 


NEXT  STATE 


OUTPUT 


ESTABLISHED 
(with  data 
queued  for 
SAPI) 


acceptable 

s_ready 


c_accept; 
c~transmit  c(s) 


ESTABLISHED 
(with  data 
queued  for 
apposite 
CPI) 


val  id 

Transmit  Command 


c_transmi t  c 
Transmit  Command(s) 


update  flow  control 


ESTABLISHED 
(with  no 
data  queued 
for 

apposite 

CPI) 


val  id 

Transmit  Command 


c_transmit_c 
Transmit  Response (s) 


update  flow  control 


HECEIVER_ 
DRAINING 
(with  data 
queued  for 
SAPI) 


acceptable 

s__ready 


c_accept 
c  transmit  c 


RECEI  VER_ 
DRAINING 


(last 

c_transmit_c 

passed) 


RECEIVER_ 

TERMINATING 


c  end  c 
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c  transmit  c 


Syntax 

Group: 
Member : 
Control : 
Text : 


FIXED (12) 
FIXED  (160 
FIXED  (8 ) 
VARIABLE 


Semantics 


Group  and  Member:  specify  the  virtual  channel  on 
Transmi t_Command  has  been  received. 

Control :  undefined. 

Text:  contains  the  service  access  protocol  message. 


wh  i  ch 


s_begin_c 


s_begin_c 


Cause 

An  SAPI  causes  an  s_begin_c  event  in  order  to  request  its  CPI 
to  establish  a  host  to  front  end  channel. 


Effect 

If  the  CPI  detects  an  inconsistency  in  the  s_begin_c  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  a 
channel  machine  is  initialized  which  then  sends  a 
corresponding  Begin_Command . 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

1 

1  OUTFUT 

1 

1 

|  COMMENT 

1 

1 

NULL 

acceptable 

1 

1  SENDER 

1  c  accept 

1 

1  initialize  channel 

s_begin_c 

1  PENDING 

1 

1  Begin_Command 

1  machine 

1 

any  other 

s  beqln  c 

1 

| - 

1  c  reject 

1 

1  log  the  error 

state 

(acceptable  or 

1 

1 

unacceptable) 

1 

1 

1 

Syntax 


Ref: 
Group: 
Member : 
Service : 
Text : 


FIXED  (?) 
FIXED  (12) 
FIXED (16) 
FIXED (16) 
VARIABLE 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 
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Group  and  Member:  specifies  the  virtual  channel  to  be 
established.  If  this  field  is  zero,  the  CPI  will  choose  the 
Group  value. 

Service :  specifies  the  number  of  the  SAPI  to  which  the  virtual 
channel  is  to  be  established. 

Text:  contains  the  service  access  protocol  message. 


s  begin  r 


s_begin_r 


Cause 


An  SAPI  causes  an  s_begin_r  event  in  order  to  respond  to 
c_begin_c  event. 


Ef  feet 


If  the  CPI  detects  an  inconsistency  in  the  s_begin_r  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  the 
channel  machine  then  sends  a  corresponding  Begin_Response . 


Channel  Machine  States 


1 

1 

CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

1 

1  OUTPUT 

1 

1  COMMENT 

1 

1 

1 

RECEIVER 

acceptable 

1 

1  ESTABLISHED 

1 

1  c  accept 

1 

1 

1 

PENDING 

s  begin  r 

1 

I  Begin  Response 

1 

! 

(Status=0) 

1 

1 

1  (Status=0) 

1 

1 

RECEIVER 

acceptable 

1 

1  NULL 

1  c  accept 

1 

1 

PENDING 

s  beqin  r 

1 

1  Begin  Response 

1 

1 

1 

(StatuuiGI) 

1 

1 

1  (Status^d) 

1 

1 

RECEIVER 

acceptable 

1 

1 

1 

1  c  reject 

1 

1 

TAKING  BACK 

s  beqin  r 

1 

1 

1 

1 

(Status=0) 

1 

\ 

1 

1 

r 

i 

RECEIVER 

acceptable 

,  NULL 

1 

1  c  accept 

I 

1 

i 

TAKING  BACK 

s  begin  r 

1 

1  Begin  Response 

1 

i 

i 

(Statuses) 

» 

_ 1 . . 

1  (Status^O) 

1 

i 

i 

any  other 

s  beqin  r 

s 

1 - 

1  c  reject 

1 

1  log  the  error 

i 

state 

(acceptable  or 

1 

1 

i 

i 

unacceptable) 

1 

1 

1 

1 

1 

1 

Syntax 

Ref : 

FIXED  (?) 

Group: 

FIXED  (12) 

Member : 

FIXED (16) 

122 


Status: 

Text: 


FIXED  (8) 
VARIABLE 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  referred  to  by  the 
c_begin_c  event. 

Status:  indicates  to  the  channel  machine  whether  the  attempt 
to,  establish  a  channel  has  been  successful.  This  field  will 
contain  one  of  the  standard  status  codes  (see  c_reject) . 

Text:'  contains  the  service  access  protocol  message. 


-  123  - 


-  s  end  -c 


s . end  c 


Cause> 


An  SAPI  causes  an  s__end_c  event  in  order  to  terminate  access 
to  the  service. 


Ef  feet 


If  the  CPI  detects  an  inconsistency  in  the  s_end_c  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  the 
channel  machine  then  sends  a  corresponding  End  Command. 
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vV 


Channel  Machine  States 


s.end  c 


CURRENT  STATE 
(SUB-STATE) 


NULL 


INPUT 


acceptable 

s_end_c 

(flushing,  from 
HFP  Maintenance 
Service) 


NEXT  STATE 


OUTPUT 


c_accept 

End_Commend 

(flushing) 


COMMENT 


SEND£R_ 

PENDING 


acceptable 
s_end_c  (flushing 
or  non-flushing) 


SENDER_ 

TAKING  BACK 


c_accept 

End_Command 

(flushing) 


RECEIVER_ 

PENDING 


acceptable 
s_end_c  (flushing 
or  non-flushing) 


NULL 


c_accept 

End_Command 

(flushing) 


SENDER_ 

TAKING  BACK 


acceptable 
s_end^_c  (flushing 
or  nori-flushing) 


c_accept 

End_Comnand 

(flushing) 


RECEI VER_ 
TAKING  BACK 


acceptable 
s_end_c  (flushing 
or  rton-flushing) 


NULL 


c_accept 
£nd_Command 
(flush) ng) 


ESTABLISHED 


acceptable 

s_end-c 

(flushing) 


SENDER_ 

TERMINATING 


c__accept 

End_Command 

(flushing) 


discard  any  gueued 
data 


ESTABLISHED 
(with  data 
queued  for 
apposite 
CPI) 


acceptable 
s  end  c  (non- 
fTushTng) 


SENDER 

DRAINING 


c_accept 


discard  any  data 
queued  for  SAPI; 
send  data  to 
apposite  CPI;  place 
End_Command  (non¬ 
flushing)  at  end  of 
send  queue; 
acknowledge  but 
discard  any  ihcomino 
messages 


ESTABLISHED 
(with  no 
data  queued 
for 

aDposi te 
CPI) 


acceptable 
s  end  c  (non- 
flushlng) 


SENDER_ 

TERMINATING 


c_accept 

End_Command 

flushing) 


(non- 


discard  any  data 
queued  for  SAPI; 
acknowledge  but 
discard  any  incoming 
messages 


SENDER 

DRA INING 

I  acceptable 

1  s  _end_c 

1  (flushing) 

1 

1  SENDER 
i  TERMINATING 

1 

...I  . 

c_accept 

End  Command 
(flushing) 

j  discard 

1  data 

1 

any  queued 

RECEIVER 

1  acceptable 

1 

!  NULL 

c  accept 

1  discard 

any  data 

DRAINING 

1  s  end  c  (flushing  ! 

End  Command 

1  queued 

1  or  non-flushing)  1 

_l_  _  1  _ 

( flushing) 

1 

.  1 

SENDER 

1 

1  acceptable 

i 

i - 

c  accept 

1 

1 

TERMINATING 

1  s  end  c  (flushing  1 

End  Command 

1 

1  or  non-flushing)  1 
_l  _  .  1  ..  . 

(flushing) 

1 

1 

RECEIVSP 

1 

1  acceptable 

i 

1  NULL 

c  accept 

1 

1 

TERMINATING 

1  s  end  c  (flushing  1 

End  Command 

! 

1  or  non-flushing)  1 

1  _  _  ! _  _  _ 

(flushing) 

1 

1 

any  other 

i 

I  s  end  c 

1 

1 - 

c  reject 

1 

state 

I  (acceptable  or 

1 

! 

1  unacceptable, 

1 

I 

1  flushing  or  non 

-  | 

1 

1  flushing) 

1 

1 

I 


Syntax 


Ref: 
Group: 
Member: 
Control : 
Text: 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8 ) 
VARIABLE 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
'Identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  be  terminated.  If 
the  Group  is  not  zero  and  the  Member  is  zero,  all  channels 
with  the  same  group  are  to  be  terminated.  If  both  Group  and 
Member  are  zero,  all  virtual  channels  are  to  be  terminated. 

Control:  The  Control  field  bit  has  the  following  meaning: 

Flush  away:  (bit  1=1)  means  immediately  flush  data 
which  is  queued  going  away  from  the  sender  of  the 
End  Command  and  terminate  the  channel.  If  this  option 
is  “not  requested  (i.e.,  if  bit  1  =  0),  the  Snd_Command 
is  not  to  take  effect  until  all  data  queued  going  away 
from  the  sender  of  the  End_Command  has  been  processed  in 

the  normal  manner. 


Text:  contains  the  service  access  protocol  message. 


<&3ase 


An  SAPI  causes  an  s_end_r  event  in  order  to  respond  to  a 
c  end  c  event. 


Effect 

If  the  CFI  detects  an  inconsistency  in  the  s_end_r  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  the 
channel  nachine  then  sends  a  corresponding  End_Response. 


Channel  Machine  States 


r 

C3S3SX7  rr*TS 

i 

3*2OT 

i  iSSE?  STATE 

M 

i 

1  OWE®? 

I 

l  oysTSt 

Ksb-ssatei 

» 

j. 

1 

1 

r 

i 

• 

M 

* 

5 

. i 

1  *rr«5t«!>Je 

3 - 

f  c 

i 

i 

3 

s  end  r  litem  EF? 

1 

l  End  Bespense 

1 

i 

3 

•saSsteMnce 

3 

1 

i 

0 

3 

Firviee) 

1 

I 

* 

1 

J. 

l 

i 

f 

i 

1 

5 

i 

* 

! 

SETEivsa 

I 

acceptable 

I  KC1£. 

X  c  acce?: 

i 

1 

this:  _2«ts 

1 

s  ead_  r 

1 

1  Ead_Besposse 

« 

J. 

3 

? 

* 

* 

1 

i 

beteivea 

I 

acceptable 

1  sris. 

*  c  accept 

i 

i 

1 

'  end  r 

1 

1  Bad  Eesyosse 

i 

# 

1 

jl 

i 

i 

1 

1  "" 

% 

i 

any  other 

1 

s  end  r 

t - 

I  c  reject 

* 

i 

state 

! 

(acceptable  or 

I 

i 

a 

1 

oracceo table} 

1 

i 

i 

? 

1, 

.1 

1 

i 

■ 

_ _ i 

Syntax 

Ref: 

Group: 

Member: 

Status: 

Text: 


FIXED (?) 
FIXED (12) 
FIXED (16) 
FIXED (8) 
VARIABLE 


Senantics 


Ref;  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_r eject  events. 

Group  and  Member:  specify  the  virtual  channel  referenced  in 
the  c_end_c  event  to  which  this  is  a  response. 

Status:  indicates  to  the  channel  machine  whether  or  not  the 
c__e nd__c  event  has  been  successfully  completed.  This  field 
will  contain  one  of  the  standard  Status  codes  (see  c_reject) . 

Text:  contains  the  service  access  protocol  message. 


s  execute  c 


s  execute  c 


Cause 

An  SAPI  causes  an  s_execute_c  event  in  order  to  send  data  to 
its  apposite  outside  the  normal  flow  of  data. 


Effect 

If  the  CPI  detects  an  inconsistency  in  the  s_execute_c  event, 
it  causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
the  channel  machine  then  sends  a  corresponding 
Execute  Command. 


Syntax 

Ref: 
Group: 
Member : 
Control : 
Text : 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED  (8 ) 
VARIABLE 


s  execute  c 


Semantics 


Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies . 

Control :  The  Control  field  bits  have  the  following  meaning: 

Attention:  (bit  0=1)  means  inform  the  SAPI  module  of 
the  arrival  of  an  Execute_Command  with  the  Attention  bit 
set. 


Synchronize:  (bit  3=1)  means  place  the  Execute_Command 
at  the  end  of  the  Sending  Queue  of  the  local  CPI. 

The  Execute_Command  is  executed  at  the  remote  CPI  as  follows: 

If  synchronize, 

place  the  Execute_Command  at  the  end  of  the  queue 
of  data  to  be  read  by  the  SAPI  module; 

otherwise, 

place  the  Execute_Command  at  the  beginning  of  the 
queue  of  data  to  be  read  by  the  the  SAPI  module. 

if  attention, 

immediately  notify  the  SAPI  module  of  the  arrival 
of  the  Execute_Command . 

The  meanings  of  the  various  bit  value  combinations  to  the 
remote  CPI  are  summarized  in  Table  1. 


Table  1 


EXECUTE  Command  Control  Field  Bit  Values 


Bit 

0123  Meaning 

0000  Place  the  Execute__Command  at  the  head  of  the 

Receiving  Queue. 

1000  Place  the  Execute_Command  at  the  head  of  the 

Receiving  Queueueue  and  notify  the  SAPI  module 
of  the  attention. 


I 


) 


i 
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i 
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■i 


s  execute  c 


0.001 

Place  the 
Receiving 

Execute_Command 

Queue. 

at  the 

end 

of 

the 

1001 

Place  the 

Execute,  Command 

at  the 

end 

of 

the 

Receiving 

Queue.  Notify  the  SAPI 

module 

of 

the 

attention. 

Text:  contains  the  service  access  protocol  message. 
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s  execute  r 


s  execute  r 


Cause 

An  SAPI  causes  an  s_execute_r  event  in  order  to  respond  to  a 
c  execute  c  event. 


Effect 

If  the  CPI  detects  an  inconsistency  in  the  s_execute_r  event, 
it  causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
the  channel  machine  then  sends  a  corresponding 
Execute_Response. 


Channel  Machine  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT 

(SUB-STATE)  I  II  I 


ESTABLISHED  I  acceptable  I  -----  |  c_accept  I  place 

I  s_execute_r  I  I  Execute_Response  I  Execute_Response  at 

I  ~  -  I  I  I  head  offsend  queue 


RECEIVER  I  acceptable  I  -----  |  c  reject  I  discard  the  message 

DRAINING  |  s_execute_r  I  I  I 


any  other  I  s_oxecute__r  I  -----  |  c_reject  I  log  the  error 

state  I  (acceptable  or  I  I  I 

I  unacceptable)  I  I  I 


Syntax 


Ref : 
Group: 
Member : 
Status : 
Text : 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8 ) 
VARIABLE 


s  execute  r 


Semantics 

Ref;  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

Status:  indicates  to  the  channel  machine  whether  or  not  the 
Execute_Command  was  correctly  formulated  and  any  requested 
action  has  completed.  The  field  will  contain  one  of  the 
standard  Status  codes  (see  c_reject) . 

Text:  contains  the  service  access  protocol  message. 
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s  identify 


s_identify 


Cause 

An  SAPI  causes  an  s  identify  event  in  order  to  identify  itself 
to  its  CPI. 


Effect 

When  a  CPI  receives  an  s__identi-fy  event,  it  attempts  to 
validate  the  SAPI.  The  attempt  may  fail  if  the  SAPI  already 
exists  or  if  it  is  not  privileged  or  if  an  inconsistency  in 
the  s_identifv  event  is  detected.  In  this  case,  the  CPI  will 
cause  a  c_reject  event.  If  the  CPI  is  able  to  validate  the 
SAPI,  it  will  cause  a  c  accept  event. 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  so 
that  it  can  identify  the  eventual  c_acoept  event  or  c_reject 
event . 
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s_identify 


Service:  specifies  the  number  of  the  SAPI  which  is  to  be 
validated  with  the  CPI. 

Note:  To  provide  protection  against  a  process  masquerading  as 
an  SAPI,  some  sites  may  require  additional  fields  for 
validating  an  SAPI. 


fs_ready 


s_ready 


Cause 

An  SAPI  causes  an  s_ready  event  in  order  to  notify  a  channel 
machine  that  it  is  able  to  accept  data. 


Effect 

If  the  CPI  detects  an  inconsistency  in  the  s_ready  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
then  if  the  channel  machine  has  data  queued  for  the  SAPI,  it 
attempts  to  transfer  the  data  to  the  SAPI  via  a  c_transmit_c 
event  and  updates  the  channel  interface  flow-control. 


Channel  Machine  States 


CURRENT  STATE 

( - - — - - — r- .  — . —  • 

1  INPUT  1  NEXT  STATE  1 

OUTPUT 

1  COMMENT 

(SUB-STATS) 

1 

1 

1 

1 

ESTABLISHED 

acceptable  1 

_____ 

c  acceot 

1 

1 

(with  no 

s  ready  1 

i 

1 

data  queued 

i 

1 

for  SAPI) 

1 

1 

i 

1 

_ 1 

ESTABLISHED 

1 

acceptable  1 

i 

c  accept 

i 

1 

(with  data 

s  ready  1 

i 

c  transnit  c(s) 

1 

queued  for 

i 

1 

SAP  I) 

1 

.  i 

i 

1 

RECEIVER 

1 

acceptable  1 

i 

c  accept 

1 

1 

DRAINING 

s  ready  1 

i 

c  transmit  c 

1 

(with  data 

i 

1 

queued  for 

1 

i 

1 

SAPI) 

1 

1 

i 

i 

1 

1 

any  other 

s  ready  1 

c  reject 

~  r 

1  log  the  error 

state 

(acceptable  or  1 

i 

1 

unacceptable)  1 

1 

i 

1 

1 

Syntax 


Ref: 
Group: 
Member : 
Msgs : 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8 ) 


s_  ready 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

Msgs:  specifies  the  number  of  Transmit_Commands  the  SAPI  is 
able  to  accept  on  this  channel.  The  value  of  Msgs  replaces 
any  previous  value. 


s  status 


s  status 


Cause 

An  SAPI  causes  an  s_status  event  in  order  to  obtain 
information  about  the  status  of  a  channel. 


Effect 

When  a  channel  machine  receives  ah  s_status  event,  it  is  to 
determine  its  present  state  and  cause  a  c_status  event  to 
notify  the  SAPI. 


Channel  Machine  States 


r 

i 

CURRENT  STATE 

INPUT 

1 

1  NEXT  STATE 

■  r 

1  OUTPUT 

i 

COMMENT 

i 

i 

(SUB-STATE) 

1 

1 

! 

1  _ 

« 

t 

i 

any  state 

acceptable 

1 

| - 

1 

f  c  status 

i 

determine  status 

1 

s^status 

1 

1 

i 

i 

1 

Syntax 

Ref:  FIXED  (?) 

Group:  FIXED{12) 

Member:  FIXED(16) 


Semantics 


Ref:  contains  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  on  which  status  has  been 
requested. 
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s  transmit  c 


Cause 


An  SAP!  causes  an  s_transmit_c  event  in  order  to  send  flow- 
controlled,  in-order  data  to  its  apposite. 


Effect 

If  the  CPI  detects  an-  inconsistency  in  the  s_transmit_c  event, 
it  causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
the  channel  machine  then  sends  a  corresponding 
T-r ansmit_Comiaand.  If  the  channel  machine  determines  that  the 
channel  interface  flow  control  should  be  updated,  it  also 
causes  a  c_ready  event. 


Channel  Machine  States 


I 


CURRENT  STATE 

1  INPUT  1  NEXT 

1 

STATE  1  OUTPUT 

“  1  " 

]  COGENT 

(SUB-STATE) 

!  1 

i 

i 

i 

i 

ESTABLISHED 

1  acceptable  1  -  - 

i 

-  -  -  1  c  accept 

i 

i 

1  s^transmit^c  1 

1  Transnit  Cornanrt 

1 

i 

i 

RECEIVER 

i  i 

1  acceptable  ]  -  - 

-  -  -  I  c  reject 

i 

I  discard  the  nc-ssage 

DRAINING 

1  s  transnit  c  1 

1  ~  1 

1 

i 

f 

i 

any  other 

1  1 

1  s  transnit  c  1  -  - 

1 

-  -  -  |  c  reject 

i 

i  log  the  error 

state 

1  (acceptable  or  t 

i 

r 

1  unacceptable)  1 

I 

1 

1 

! 

Syntax 


Ref: 
Croup: 
Member : 
Control : 
Text.: 


FIXED  (?) 
FIXED (12) 
FIXED  (16) 
FIXED  (8 ) 
VARIABLE 


5  transmit  c 


Semantics 

Ref:  specifies  a  unique  identifier  Supplied  -  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events* 

Group  and  Member:  specify  the  channel  to  which:  this  event 
applies. 

Control:  is  undefined. 

Text:  contains  the  service  access  protocol  message. 


2isittSaJ5z3taj  3s &£  -  Proas  Ko3 

Gocrnnna;  cat 5  oca 


SVflTKAUSIMS  BOSS'  -  fBOTB*  El©  CSWITTCICSOTSTC 


To  initialize  Cor  restart!  host  —  ffrsct  ecsS  csnrmrcscatLicKa,,  sfce 
following  segaence  off  steps  west  fee  ttafeeas 

ECST:  1J  The  host  EP?  Maintenance  Service  causes 

an  sjB®fl_c  erect  with  GrcaKss^fieJiSier*®- 

BSST:  2|  The  host  CPI  csf^ses  a  fleshing  cjea3_c 

erect  for  each  chaccel  and  sends  a 
finishing  Ehd_Coinnracid  with  GSroao  = 
Marcher  =  ®  to  t  ;e  front  end  CPI. 

FRffiKT  EsES#:  3J  ’She  front  end  CPI  caoses  a  Sloshing 

c__en sd_c  event  for  each  channel  and 
seeds  acs  EDSJSesgsosse  with  Srocp  = 
Marcher  =  25  to  the  host  CP£. 

HOST:  4}  She  host  CPS  ceases  a  c_end_r  erect  for 

the  host  HFP  Maintenance  Service  to 
indicate  that  all  connections  hare  been 
tensisaated. 

BOTH:  5)  Iff  necessary,  the  host  srJb  the  front 

end  reinitialize  linfe  level 
cojaauralcation.  3ow  this  Is  done  Is 
Installation  dependent. 

HOST:  6)  The  host  ErP  Maintenance  Service  ceases 

an  s_beginjc  event. 

ROST:  7)  Tha  host  CPI  sends  a  BeginjComsand  with 

Service  code  =  <3rP  Maintenance  Service 
Code>. 

FRONT  END:  3)  The  front  end  CPI  causes  a  c_feegin_c 

event  for  the  HFP  Maintenance  Service. 

FRONT  END:  9)  The  front  end  HFP  Maintenance  Service 

causes  an  s_jbegin_r  with  Status  =  0, 

FRONT  END:  10)  The  front  end  CPI  sends  a 

Begin_Response  with  Status  =0. 

HOST:  11)  The  host  CPI  causes  a  c_begin_r  event 

with  Status  =  S  for  the  HFP  Maintenance 
Service. 


When  the  above  steps  have  been  completed,  host  -  fron*-  end 
communication  may  proceed  (i.e.,  virtual  channels  nay  be 
established) . 
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SPECIFYING  SERVICE  ACCESS  PROTOCOLS 


Introduction 


Together,  the  link  and  channel  protocols  provide  a  reliable 
virtual  communications  medium  for  the-  service  access  protocols. 
Each  service  access  protocol  provides  the  host  with  access  to  a 
specific  service  offloaded  to  the  front  end/  e.g.,  a  network  data 
transport  service  or.  a  network  virtual  terminal  (for  a  detailed 
discussion,  see  Day,  J.;  Offloading  ARPANET  Protocols  to  a  Front 
End,  CAC  Document  No.  230,  1977).  Since  each  service  access 
protocol  definition  depends  on  the  service  to  which  it  provides 
access,  the  service  access  protocols  cannot  be  specified  in  the 
present  document.  However,  to  ensure  uniformity,  consistency, 
and  completeness,  the  forms  that  service  access  protocol 
specifications  and  adaptation  descriptions  (see  below)  should 
follow  have  been  specified. 


Specifications  and  Adaptation  Descriptions 
Each  service  access  protocol  is  described  by 

a)  a  service  access  protocol  specification,  and 

b)  a  set  of  service  access  protocol  adaptation 
descriptions. 

A  serviG?  access  protocol  specification  defines  the  rules  for 
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communication  between  apposite  SAPIs  in  the  host  and  in  the  front 
end.  The  unit  of  service  access  protocol  communication  is  the 
service  access  protocol  message.  Service  access  protocol 
messages  correspond  to  channel  protocol  messages,  i.e.,  there  is 
a  service  access  protocol  begin_command  corresponding  to  the 
channel  protocol  Begin_Command ,  a  service  access  protocol 
transmit_command  corresponding  to  the  channel  protocol 
Transmit_command,  etc.  (To  distinguish  service  access  protocol 
messages  from  channel  protocol  messages,  service  access  protocol 
messages  are  written  all  lower-case.)  Service  access  protocol 
messages  are  carried  by  the  TEXT  field  of  the  corresponding 
channel  protocol  messages.  Thus,  specifying  a  service  access 
protocol  amounts  to  defining  the  TEXT  fields  of  the  channel 
protocol  messages  in  terms  of  the  corresponding  service  access 
protocol  messages. 

Since  choices  must  be  made  in  implementing  a  service  access 
protocol  for  a  given  host  and  front  end  (e.g.,  in  handling 
mismatch  between  host  and  front  end  word  sizes  and/or  character 
sets) ,  an  adaptation  description  describing  these  choices  must 
also  be  made  for  each  implementation  of  the  service  access 
protocol . 
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Service  Access  Protocol  Specifications 


Each  service  access  protocol  specification  shall  have 
following  form: 


Cname  of  the  service  to  which  access  is  provided> 
Service  Access  Protocol 
Specification 


I.  HFP  Code  Number  for  the  <to  be  accessed>  Service: 

Give  the  HFP  Code  Number  for  the  service  to  be 
accessed . 


II .  Description  of  the  Service  to  be  Accessed : 

Describe  the  service  to  be  accessed.  The  description 
of  the  service  is  to  include: 

a)  its  purpose, 

b)  background  information, 

c)  an  overview  of  its  operation, 

d)  optional  features, 

e)  supporting  services  that  must  also  be 
implemented,  and 

f)  an  overview  of  the  offloading  strategies  relevant 
to  this  service, 

g)  references  to  relevant  documents. 


Ill .  Message  Use 

Describe  how  each  service  access  protocol  message  is 
used.  The  messages  are  to  be  discussed  in  the  order: 


begin_command 

(Section 

III. A) 

begin_response 

(Section 

III.B) 

end_command 

(Section 

III.C) 

end_response 

(Section 

III.D) 

the 
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execute_command  (Section  III.E) 

execute_response  (Section  III.F) 

transmit_command  (Section  III.G) 

Note:  the  TEXT  field  of  a  Transmit_Response  is  never 

passed  to  an  SAPI  by  a  CPI.  Therefore,  there  is  no 
service  access  protocol  transmit_response 

corresponding  to  the  channel  protocol 

Transmit_Response. 

The  description  of  each  message  is  to  have  the 
following  form: 

III.<X>.1  When  Sent 

Describe  the  circumstances  under  which  this 
message  is  sent. 

III.<X>.2  Action  on  Receipt 

Describe  the  actions  to  be  taken  by  the 
receiver  of  this  message. 

III. <X> . 3  Syntax 

Define  the  syntax  of  the  service  access 
protocol  message.  Include  the  minimum 
length  of  each  field.  For  the  detailed 
format  of  this  section,  see  "Specifying 
Fields"  below. 

III.<X>.4  Semantics 

Define  the  semantics  of  each  field  defined 
in  III.<X>.3  "Syntax".  Each  definition  will 
include  at  least: 

a)  the  meaning  of  each  value  for  each 
field , 

b)  the  restrictions  on  the  values  for  each 
field, 

c)  the  default  value  for  each  field  and 
how  it  is  expressed,  and 

d)  the  interaction  of  the  values  of  each 
field  with  the  meanings  of  other 
fields . 
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Specifying  Fields 

Service  access  protocol  messages  are  carried  by  the  TEXT  field  of 
their  corresponding  channel  protocol  messages.  TEXT  in  channel 
protocol  messages  consists  of  fields.  The  value  of  each  field 
represents  a  datum.  The  datum  may  be  simple,  e.g.,  a  network 
port  number.  Or  the  datum  may  be  a  complex  of  data,  e.g.,  the 
set  of  parameters  necessary  for  initiating  a  network  connection. 

The  data  represented  by  a  field  may  always  require  the  same  field 
length,  e.g.,  ARPANET  socket  numbers  always  require  32  bits.  A 
field  representing  such  fixed-length  data  is  called  a  fixed 
field.  It  consists  of  a  bit  string  (at  least)  long  enough  to 
represent  the  data. 

The  data  represented  by  a  field  may  require  varying  field 
lengths,  e.g.,  user  names  consisting  of  character  strings.  A 
field  representing  such  variable-length  data  is  called  a  variable 
field.  It  consists  of  a  fixed  length  count  part  followed  by  a 
bit  string  content  part.  The  content  part  must  be  long  enough  to 
represent  the  datum.  The  value  of  the  count  part  is  the  length 
of  the  content  part.  The  length  of  the  count  part  must  be  chosen 
to  be  large  enough  to  represent  the  length  of  the  largest 
conceivable  content  part.  This  length  may  be  expressed  in  bits, 
characters,  bytes,  words,  or  any  other  convenient  units.  The 
units  must  be  specified  together  with  each  field  in  the  Syntax 
section  (if  known  when  the  service  access  protocol  is  specified) 
and  in  the  adaptation  description. 
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The  data  represented  by  a,  variable  field  may  be  complex,  and  the 
fields  representing  £he  values  -of  the  data  may  themselves  be 
fixed  or  variable,  simple  or  complex.  In  some  cases,  it  may  be 
desirable  to  have  a  fixed  qualifier  field  as  the  -first  field 
representing  a  complex  datum.  This  qualifier  field  will  aid  in 
the  parsing  and  interpretation  of  the  rest  of  the  fields. 

A  service  access  protocol  specification  describes  the  features  of 
the  service  access  protocol  common  to  all  implementations.  Word 
sizes  and  convenient  data  alignment  boundaries  may  differ  among 
implementations.  Therefore,  a  service  access  protocol 

specification  cannot  prescribe  the  field  formats  for  all 
implementations.  But  a  service  access  protocol  specification  can 
and  must  specify  what  fields  are  to  be  present,  their  content, 
and  their  minimum  lengths. 

A  fixed  field  is  to  be  represented  by: 

<field  name>  :  FIXED (<length>) 

A  variable  field  is  to  be  represented  by: 

<field  name>  :  VARIABLE (<count  part  length>) 

A  complex  field  is  to  be  represented  by: 

<field  name>  :  COMPLEX  (<count  part  length>) 

<field  name>  :  . 

•  •  • 

*  •  • 

*  •  ♦ 

<field  name>  :  . 

where  hierarchy  of  structure  is  indicated  by  indentation. 
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Defaults 

The  default  value  is  expressed  by: 

a)  the  absence  of  the  field,  if  it  is  part  of  a  complex 
field  and  all  subsequent  fields  which  are  part  of  the 
complex  field  are  also  absent; 

b)  zero  length,  if  the  field  is  a  variable  field; 

c)  a  predetermined  value  (e.g.,  zero),  if  the  field  is  a 
fixed  field  which  does  not  meet  condition  a) . 


Adaptation  Descriptions 


Adaptation  Descriptions 


Each  service,  access  protocol  adaptation  description  shall  have 
the  following  form: 


<name  of  the  service> 
Service  Access  Protocol 
Adaptation  Description 


Section  I_.  Description  of  the  Adaptation 

I. A  Service  Access  Protocol 

Give  the  complete  reference  citation  for  the 
service  access  protocol  specification  on  which 
this  adaptation  is  based,  including  document 
numbers,  date,  etc. 

I.B  Applicable  Hosts  and  Front  Ends 

Present  a  table  showing  the  classes  of  hosts  and 
front  ends  for  which  this  adaptation  is  intended. 

I.C  Supported  Facilities  List 

Present  a  table  showing  the  optional  facilities 
supported  by  this  adaptation.  A  more  detailed 
discussion  of  each  facility  supported  is  to  be 
found  in  section  II. B. 

I. D  Unsupported  Facilities  List 

Present  a  table  showing  the  optional  facilities 
not  supported  by  this  adaptation.  A  more  detailed 
discussion  of  the  limitations  of  this  adaptation 
is  to  be  given  in  section  II. C. 

Section  I I .  Discussion  of  the  Adaptation 

II.  A  Distribution  of  Functions 

Discuss  the  scheme  or  schemes  supported  by  this 
adaptation  for  distributing  functions  between  the 
host  and  the  front  end. 

II. B  Optional  Facilities  Supported 

Discuss  each  of  the  facilities  listed  in  section 
I.C.  This  section  is  to  contain  a  subsection  for 
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■each  of  the  facilities. 

IIVC  Unsupported  Optional  Facilities 

Discuss  the  optional  features  of  thfe  service 
access  protocol  that  are  not  implemented  and 
discuss  the  general  limitations  of  this 
adaptation. 

II. D  Additional  Facilities 

Discuss  in  detail  any”  facilities  not  provided  for 
or  left  undefined  by  the  service  access  protocol. 

II. E  Host  System  Considerations 

Discuss  how  the  host  SAPI  must  manipulate  various 
host  system  primitives,  system  commands,  user 
programs,  etc.  to  perform  its  functions. 

II.F  Translation  Considerations 

II.F.l  Command  Translation 

Discuss  the  problems  of  translating  command 
functions  from  those  of  the  offloaded 
protocol  into  equivalent  functions  in  the 
host  system. 

II.F. 2  Data  Translation 

Discuss  any  data  representation  mismatch  (see 
below),  the  translation  problems  involved, 
and  how  they  are  solved  in  this  adaptation. 

II. G  References 

Give  references  to  all  relevant  documents. 


Section  III.  Definition  of  the  Adaptation 

III. A  Command  Translation 

Describe  in  detail  the  command  translations  that 
are  performed  by  the  host  SAPI.  For  example,  if 
the  service  defines  a  function  called  "Intersect", 
then  this  section  is  to  give  a  detailed 
description  of  how  the  host  SAPI  performs  this 
function. 
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IJI.B  Data  Translation  . 

Describe  in  detail  any  data  translations  that  are 
performed  by  the  SAPIs.  For  example,  if  ASCII  is 
converted,  to  EBCDIC,  the  conversion  table  is  to  be 
given.  -  _  ■ 

III.C  Syntax 

Describe  the  syntax:  of  each  service  access 
protocol  message,  if  it  differs  from  the  service 
access  protocol  specification.  The  description  is 
to  be  in  the  same  order  and  in  the  same  form  as  in 
the  service  access  protocol  specification.  It  may 
be  convenient  to  define  additional  facilities  and 
fields  at  this  time. 


Adaptation  Descriptions. 

Data  Representation  Mi snatch 

The  data  representation  mismatch  problems  which  must  be  addressed 
by  an  adaptation  description  are: 

a)  character  set  mismatch  and 

b)  data  unit  size -mismatch. 

The  character  sets  and  codes  employed  by  the  host  and  front  end 
may  differ.  Any  translation  required  is  to  be  specified  in  the 
adaptation  description. 

The  sizes  of  the  data  units  employed  by  the  host  and  the  front 
end  may  differ.  This  may  require  redefinition  of  the  syntax  of 
service  access  protocol  message  fields  in  order  to  place  them  on 
convenient  boundaries.  This  redefinition  of  fields  may  involve: 

a)  extending  fields  beyond  the  minimum  lengths  specified 
in  the  service  access  protocol  specification,  and/or 

b)  inserting  padding  fields  where  required. 

Any  transformation  of  data  from  one  unit  size  to  another  is  to  be 
specified  in  the  adaptation  description. 
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Bast  Front-End  Protocol 
'Service  Access -Protocol  Interpreter 
State  Table 


This  section  contains  the  detailed  state  transition  table  for  assy 
SAPI  interacting  with  a  channel  machine.  'Shis  state  table  mast 
be  a  subset  of  the  state  table  for  any  SAFI.  'She  SAP!  and  the 
channel  machine  cosarcanicate  via  channel  interface  events.  Ihe 
channel  machine  checks  the  events  from  the  SAP'S  for  consistency 
and  rejects  any  inconsistent  events. 


Notation 


States.  All  state  names  are  printed  with  all  capital  ietters- 
If  the  state  name  consists  of  two  or  more  words,  the  words  are 
separated  by  an  underscore  (_) .  Examples:  null,  SENSES*  P3E?Snas. 


Events.  All  event  nanes  of  events  caused  by  a  £AJ?I  are  either  of 
the  forrax 


s_< interface  event  nane>_<event  suffix> 

where  <inter£ace  event  nane>  is  one  of  the  following: 

begin 

transact 

execute 

end 

and  <event  suffix>  is  either 

c  indicating  a  Command 

or  r  indicating  a  Response 

or  of  the  form: 


s_<interface  event  nane> 

where  <interface  event  nane>  is  one  of  the  following: 

ready 

identify 

status 
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SAFI  Stases 


All  cswas  ©£  «v*stts  ©aas*3  fop  a  CPS  ©e  ©me  ©£  its  channsel 

aracbsces  are  either  ©f  ttfoe  ff©amis 

CjCSratterfface  evecst  c*rr2»_<£V£c£  saf£ix> 

wfcere  Cicsfcerface  erect  Ea5me>  is  ©me  ©f  the  fallowing: 

befits 

transmit 

execute 

gcd 

ant3  <«event  sss££ix>  is  the  sene  as  above 
©r  ©£  the  form: 

cjCiesterface  event  cane> 

where  Ciosterfsce  event  came>  is  ©me  of  the  following: 

ready 

states 

accept 

rejjecfc- 

Event  najees  are  all  lower  case.  Examples:  s__beg£n_c,  c_begin_c, 
s_ready,  c_ states. 

A  detailed  description  of  each  event  can  fee  found  in  the  section 
entitled  “Channel  Interface". 


UlOKsnciafcure 


Acceptable/fesacceptable:  an  event  nay  be  found  unacceptable  by  an 
SSPi  if  the  SAP!  detects  an  error  in  the  Text  field  or  if  it  is 
unable  to  fulfill  the  request  described  in  the  Text  field  due  to 
lack  of  resources,  insufficient  access  rights,  etc. 

States  ^  0=  an  event  with  this  annotation  indicates  that  the 
event  to  which  it  is  a  response  was  not  successful. 

Generic  Requests:  a  process  or  user  of  an  SAP I  generates  inputs 
to  it.  These  inputs  are  modelled  in  the  state  table  as  “generic 
inputs".  They  are  “request  for  service",  "request  fcernination", 
"send  data",  and  "send  Execute_Connand*.  This  specification  d^es 
not  define  the  parameters  or  any  other  characteristics  of  the 
intar face  between  an  5API  and  any  higher  level  processes.  It 
merely  ecognizes  the  existence  of  such  interactions.  This 
interface  cay  be  defined  by  the  service  level  protocol  or 
adaptation  descriptions.  It  nay  be  highly  specific  not  only  to 
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SAPI  States 


the  SAP!  but  also  to  the  environaent  in  which  it  is  implemented. 


SAPI  States 


NULL;  An  SAPI  in  this  state  is  not  active. 


PENDING;  An  SAPI  in  this  state  has  requested  its  CPI  to  atteapt 
to  establish  a  virtual  channel  to  its  apposite.  It  has  caused  an 
s_begin_c  event  and  is  waiting  for  a  cheginr  event.  (The 
channel  machine  has  sent  a  Begin_Coasand  and  is  waiting  for  a 
Seginjtesponse . } 

TAKING  BACK:  An  SAPI  in  this  state  has  been  requested  to 
terminate  comnursicaticn  with  its  apposite  while  it  was  in  the 
PENDING  state  and  has  caused  an  s_end_c  event  before  the 
cjbeginjr  event  has  cone  from  the  channel  nachine. 

ESTABLISHED;  An  SAPI  in  this  state  has  established  connanication 
with  its  apposite. 

TERMINATING;  An  SAPI  in  this  state  has  been  requested  to 
terminate  communication  with  its  apposite,  and  has  caused  an 
s_end_c  event  and  is  waiting  for  the  c_end_r  event  acknowledging 
termination  by  its  apposite. 
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sapi  states 
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SAPI  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT 

(SUB-STATE)  !  II  | 


ESTABLISHED  I  request  I  TERMINATING  I  s_end_c  (flushing 

I  termination  I  I  or  non-flushing  as 

I  (flushing  or  I  I  requested) 

I  non-flushing)  I  I 


ESTABLISHED  I  send  data  I  -----  |  s_transmit_c  I  transfer  data'  as 

I  II  I  allowed  by  c__ready 


ESTABLISHED  I  send  I  -----  |  s_execute_c 

I  Execute  Command  I  I  ~ 


ESTABLISHED  I  c__end_c  I  NULL  I  s_end_r  I  terminate  service 

I  (flushing  or  I  j  ~  ~  I  for  user 

I  non-flushing)  I  I  I 


ESTABLISHED  I  c_execute_c  I  -----  |  s_execute_r 


ESTABLISHED  I  c  execute  r 


ESTABLISHED  I  c_reject  I  -  -  -  -  -  I  attempt  error 

I  ~  I  I  I  recovery 


ESTABLISHED  I  c_transmi  t__c  I  -  -  -  -  -  I  -  -  -  -  -  |  transfer  data  as 

I  "  I  I  I  allowed  by  s_reariy 


ESTABLISHED  I  any  other  event 
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HFP  Maintenance  Service 


HFP  MAINTENANCE'  SERVICE 


Introduction 

The  HFP  Maintenance  Service  provides  the  management  functions  'for 
the  host  to  front  end  protocols.  Since  the  present  document 
fully  specifies  only  the  channel  protocol,  these  management 
functions  are  here  defined  only  in  relation  to  the  channel 
protocol.  The  HFP  Maintenance  Service  may  also  provide 
management  functions  for  the  link  protocol  and  the  service  access 
protocols.  Whenever  such  additional  management  functions  are 
defined  for  the  HFP  Maintenance  Service,  their  definitions  should 
be  incorporated  into  the  present  specification. 


The  HFP  Maintenance  Service  provides  three  management  functions 
for  the  channel  protocol.  These  are: 

1)  initializing  host  -  front  end  communication, 

2)  recording  CPI  error  reports,  and 

3)  communicating  CPI  error  reports  between  apposite  CPIs. 


The  HFP  Maintenance  Service  is  implemented  in  both  the  host  and 
in  the  front  end.  The  two  HFP  Maintenance  Service 
implementations  communicate  via  an  HFP  Maintenance  Service  Access 
Protocol,  which  uses  the  channel  protocol  implementation  as  its 
communications  medium. 
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HEE  Maintenance  Service 


HFP  Maintenance  Service 
Service  Protocol 
Specification 


!.♦.  HFP  Maintenance  Service  Code  Number 
0  (Zero) 


II .  Description  of  the  HFP  Maintenance  Service 

The  HFP  Maintenance  Service  provides  management  functions  for 
the  link,  channel,  and  service  access  protocol  interpreters 
(see  Introduction,  above) . 

Synopsis  of  Message  Use 

begin  command 


is  sent  by  the  host  HFP  Maintenance  Service  to 
initiate  (or  restart)  host-front  end 

communication . 

begin  response 

is  sent  by  the  front  end  HFP  Maintenance  Service 
to  confirm  the  establishment  of  communication, 
end  command 


is  sent  by  either  the  host  or  the  front  end  HFP 
Maintenance  Service  to  terminate  channel  level 
communication . 

end  response 

is  sent  to  confirm  that  channel  level 
communication  has  been  terminated. 

execute  command 


not  used 
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HFP  Maintenance  Service 


execute  response 
not  used 

transmit  command' 

is  sent  by  either  the  host  or  the  front  end  HFP 
Maintenance  Service  to  communicate  error  reports 
made  by  the  CPIs. 


HFP-  Maintenance  Service 


III.  Message  Use 

III  A.  begin  command 
III  A  1.  When  sent 

A  begin_command  is  sent  by  the  host  HFP 
Maintenance  Service  when  the  host  HFP 
implementation  is  ready  to  engage  in  channel 
level  communication. 

Ill  A  2.  Action  on  receipt 

When  the  front  end  HFP  Maintenance  Service 
receives  a  begin_command,  it  determines 
whether  or  not  the  front  end  HFP 

implementation  is  prepared  to  engage  in 
channel  level  communication,  and,  if  so,  it 
sends  a  begin_response. 

Ill  A  3.  TEXT  field  syntax 


empty 

III  A  4.  TEXT  field  semantics 
irrelevant 
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HFP  Maintenance  Service 


III  B.  begin  response 


III  B  1.  When  sent 

A  begin_response  is  sent  by  the  front  end  HFP 
Maintenance  Service  when  the  front  end  HFP 
implementation  is  prepared  to  engage  in 
channel  ievel  communication. 

Ill  B  2.  Action  on  receipt 

After  the  host  HFP  Maintenance  Service 
receives  a  begin_response,  it  proceeds,  to 
handle  error  reports  from  the  CPI. 

Ill  B  3.  TEXT  field  svntax 


empty 

III  B  4.  TEXT  field  semantics 


irrelevant 


HFE  Maintenance  Service  - 


III  C.  end  command 
III  Cl.  When  sent 

An  end_command  is  sent  by  either  HFP 
Maintenance  Service  to  terminate  channel 
level  communication. 

Ill  C  2.  Action  on  receipt 

When  the  host  or  front  end  HFP  Maintenance 
Service  receives  an  end_command,  it  should 
notify  all  SAPI's  using  the  HFP  that  service 
is  ending,  "clean  up",  and  send  an 
end_response. 

Ill  C  3.  TEXT  field  syntax 
empty 

III  C  4.  TEXT  field  semantics 
irrelevant 
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BFP  Mascatesaace  Service 


III  P.  end  response 
III  I?  1.  «g«en  sent 

An  emrSjresporase  is  sent  £®  confirms 
channel  level  commaniea  tiers  has 
terminated. 

IIS  O  2.  Action  en  geceS.pt 
none 

III  9  3.  TEX'?  field  svntaz 


empty 

III  P  4.  TEXT  field  semarat ics 
irrelevant 


that 

&*em 


-  169 


115  S.  eeggcsSe  ogrmrraaj 

aot  c ss©3 

III  g.  eacegatc  resgnaitse 
not  asedi 
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III  S.  fcsraasraifc  COTnmaaaS 
III  &  l.  OfeccB  seat 

A  fcrajasraifc^comsiaesa  Is  scat  fcy  either  nT? 
ateintenance  Service  to  camrceraic^te  an  error 
report  m«$£  tv  t&e  channel  protocol  interpreter. 

Ill  G  2.  Action  on  receipt 

HSren  as  SFP  waiGteicsace  Service  receives  a 
traas3nit_c<wniraci3  notifying  it  of  aa  error,  it 
shcsaldJ  log  the  error  an y3  if  possible  attempt  any 
error  recover-f. 

Ill  G  3.  TEX?  field  synfcaz 

Cause:  F1XEPJS5 

Header:  FIXES  £72) 

Diagnostics:  CSWPLEXf?) 

111  G  4.  TEXT  field  semantics 

III  G  4  (a) .  Cause 

T-us  field  will  contain  one  of  the  Status  codes. 
Ill  G  4  (by.  Header 

This  field  contains  the  channel  protocol  HEADER 
for  the  nessage  in  which  the  error  was  detected. 

Ill  G  4  {c) .  Diagnostics 

This  field  will  contain  any  other  diagnostic 
information  that  the  CPI  can  provide  relating  to 
the  error.  If  this  transnit_coraaand  is 
reporting  an  error  at  the  service  access  level, 
this  field  may  contain  the  erroneous  service 
access  protocol  message. 
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Status  Codes 


Channel  Protocol  Response 
Status  Codes 


Status  leaning 

0  Cosanand  was  successful. 

1  Channel  non-existent:  the  Group  and  Member  fields 
of  a  Command  (other  than  a  BeginjComnand) 
referenced  a  channel  unknown  to  the  receiving 
CPI. 

2  Illegal  state:  a  message  was  received  referencing 
a  channel  which  was  in  a  state  for  which  the 
Command  is  an  illegal  input. 

3  Command  not  implemented:  a  Command  was  received 
whose  Type  was  legal  but  not  implemented. 
Currently  this  can  only  be  a  Begin_Coramand  or  an 
ExecutejCommand. 

5  Message  too  long:  the  number  of  bits  in  the 

Command  exceeded  the  maximum  permitted  by  the 
receiving  CPI. 

6  Service  access  protocol  message  error:  an  error 

in  the  service  access  protocol  message  contained 

in  the  TEXT  field  of  the  Command  was  detected  by 
the  SAPI. 

7  Illegal  Control  field  value:  the  Control  field 
of  the  Command  contained  an  undefined  value. 

32  Channel  in  use:  the  channel  referenced  in  the 

Begin_Command  was  already  assigned  (i.e.,  not  in 
the  NULL  state)  . 

33  Service  not  implemented:  the  Service  field  in  the 
Begin_Command  specified  an  SAPI  not  implemented 
at  the  receiving  site. 

34  Insufficient  resources:  the  receiver  of  the 
Bagin_Comniand  did  not  have  sufficient  resources 
for  establishing  the  host  to  front  end  channel. 

35  Out  of  sequence:  a  Transmit_Command  was  received 

and  discarded  whose  Seq  field  was  neither  in 
sequence  (equal  to  [<last  received>  +  1])  nor  a 
duplicate  (between  [<last  received>  -  7]  and 

<last  received>  inclusive)  (see  Flow  Control) . 
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Channel  Protocol  Response 
Status  Codes 


36  Out  of  window:  a  Transmit_Coir.mand  was  received 
and  discarded  whose  Seg  field  was  between  (<last 
received>  +  Credit  +  1)  and  (<last  received>  +  8) 
inclusive  (see  Flow  Control) . 

37  Bad  channel  polarity:  the  high-order  bit  of  the 
Group  field  in  the  Begin_Command  had  the  wrong 
value. 

38  Service  not  operational:  the  Service  field  in  the 
BeginjCommand  specified  an  SAPI  which  is 
implemented  at  the  receiving  site  but  which  is 
temporarily  unavailable. 

39  Command  discarded:  the  channel  machine  received 
a  Transmit_Command  or  ah  E:<ecute_Command ,  was  in 
the  SENDER_DRAINING  or  SENDER  jrERMINATING  state, 
and  has  discarded  the  Command  without  passing  its 
TEXT  field  to  the  service  access  level. 
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